Reaper Treant needs to damage player with attack animations

[mysterymagination]

For this we'll need separate hit boxes on the arms/hands or something; the single capsulecomponent around the treant isn't good enough.

[mysterymagination]

I added other collision shapes to the arms, head, torso, and legs. I think with collision channel fiddling that should allow for hit and hurtboxes (with extra damage for headshots or shots in the eyes or something). Maybe even something to shut down his arms and/or legs by targeting them.
todo: how do I get the hitboxes and hurtboxes to move with his animations? They are children of his mesh, but does the animation actually count as a mesh transform? Even if it does, there's currently no association between e.g. specifically the right arm section of the mesh and the right arm hitbox; maybe sockets or bone associations for the collision shapes need to be employed? EDIT: yep, just needed to assign bones in the parent socket fields of the collision shapes

[mysterymagination]

todo: add collision channels to allow for hurtboxes (treant takes damage when these are hit by an attack), hitboxes (player takes damage when these connect, at last during an attack action/animation), and both (e.g. arms can both inflict and receive damage)

• one way I've seen to do this, without collision channels, is to add logic to the projectiles to check if the name of the object they collide with contains a certain string e.g. 'arm', 'head' etc. This could work, but would require me to make the hitboxes into BPs with their own event graph so they can check in turn if they have collided with various hurtboxes of the player. Seems like a naive workaround to avoid using collision channels to automatically achieve the same thing.

  • weeell maybe this is the way to go. I saw another tutorial doing essentially the same, but going a step further and manually checking for collision via actor overlap (for some reason). The collision channel usage I've seen looks more like collision filtering only, which doesn't super help us super much. Technically you could use it to make sure the hit/hurtboxes only apply to attacks/projectiles (ignoring anything else that might register as collision), but that won't be enough to figure out who's damaging what -- for that I think you need logic in the actual collision event, which means we'll need to be able to add logic to the hit/hurtboxes themselves.
  • I waffled about making a custom Hitbox C++ class that would be an Actor or something and have via composition some UPrimitiveComponent stuff to which it assigned custom hit behavior logic, but then I realized I could just short that whole process and assign the custom handler logic directly to OnComponentHit delegate functions inside BP_ReaperTreant itself; that guy knows about his arms and legs and so forth, so he can just set up his own handler logic for 'em.
  • For the sake of reusability on other Monsters we may want to factor out the logic to functions within Monster.cpp and then just have the BP part assigning those functions as delegates associated with the hit event on whatever the monster instance's particular parts need hitboxes with similar behavior.
  • Alternatively, we could subclass particular UShapeComponents like UCapsuleComponent as e.g. HitboxArm and install the specific handling logic there instead; that might be best for reusability.

  • So I've gone a bit overboard with the anatomy arch and levels of abstraction for defining anatomical form and function... but anyway we're getting somewhat close to being able to place a UArmCapsuleComponent on the treant and then be able to hook up that component's oncomponenthit event to I guess the ProcessHit() fn of the UArmCapsuleComponent::GetAnatomyUnit() return value? That's all well and good, but the API under the hood is a bit fucked -- we can cast the hitting component to IAttacker and the hit component to IDefender and work through those interfaces (although in the case of ASnowball, we implemented IAttacker on the AActor rather than a component so we'd need to somehow know to use the hitting component's owner AActor in that case...), but the IAttacker interface fn CalculateDamageTx calls for an attack name and an attacking AActor, neither of which are easily available. We could look up the attacking AActor probably through the UPrimitiveComponent API but we ideally wouldn't and we certainly don't know anything about the attack name (and shouldn't) when we're processing an incoming hit.

    • Problems:

      1. We have a mix of Actors and Components as implementations of IAttacker, but only Components communicated as the attacker in a hit event.
      2. For this I'd say going forward look to put the impl on whatever the actual colliding component is going to be, but for now the Snowball situation is fine because the Snowball receives the event and can process its tx damage calc however it pleases inside the Actor's OnHit handler fn.
      3. We want CalculateDamageTx() to take an attack name and attacker IBattleStatsBearer impl, but on the rx end at least we don't have that information.
      4. What I'm doing currently is having the tx drive the engagement, calculating the base damage and then calling the defender's rx calc fn; that way the rx doesn't need to know anything about the attack origin details and it seems to fit better with how UE4 broadcasts collision events (favoring sending the event to the object in motion, which is likely the attacker).
      5. There's confusion in my API re: handling hits as the attacker vs. as the defender, especially for something like a UAnatomyUnit that can serve as both. My confusion here is mostly because I was primarily considering the single case of a UArmCapsuleComponent being the defender against an ASnowball, but also because I'm not sure how UE4 would handle the case where both parties involved in a collision have an OnComponentHit event -- do they each get the onhit event fired with roles reversed? Is velocity taken into account to figure out which one is responsible (or most responsible) for the collision?

      6. So assuming the collision works by sending the collision event to both parties involved with the roles swapped (the event a given registered party gets is the one in which their component is the striking component), what we could do is:

         • have a top level Actor implement the onhit handler

         • handler looks up the UAnatomyUnit owned by the striker component and casts that to IAttacker to calc tx damage

         • TODO: what about IAttackers who aren't implementers of IAnatomy, e.g. ASnowball? Maybe we should move the IAttacker interface up to the UPrimitiveComponent subclass level so we can be assured that we'll have an IAttacker and/or IDefender in a collision event, and then it will be up to the impl to look up anatomy or whatever. Arguably mucks up my form and function partition but not a lot and we have to work within the UE4 API which just gives us UPrimitiveComponents and maybe an owning AActor... Also doesn't super work with Snowball, but that gal already knows how to handle herself.

           • I don't super like this bubbled up to e.g. ExtremityCapsuleComponent approach because it means we'll have to copy the same default behavior around to each of the categorical UPrimitiveComponent subclasses (HeadBoxComponent, BodyBoxComponent and nay others that come up) since they are siblings derived from an engine source class. It might be better to use composition instead and have an e.g. Weapon class that implements IAttacker and an Armor class that implements IDefender, and an ExtremityCapsuleComponent HAS one of each of these. That way we could toss default weapons and armor processing around and customize where we want in the BP or CPP instances as needed.

         • handler for anatomy collision components looks up the UAnatomyUnit owned by the stricken component and feeds the tx damage in to its calc rx damage function, which takes resistances etc. into account and calls ApplyPointDamage().

[mysterymagination]

todo: add attack animation based on behavior tree state

• this is blocked by issue #47

[mysterymagination]

todo: wtf can't I use a TPair in IDefender?! I keep getting the dreaded Error: Unrecognized type 'TPair' - type must be a UCLASS, USTRUCT, UENUM, or global delegate. from UHT. I guess if I can't use that for no reason, then I should change the API so it accepts a damagetype as input and it's up to the impl to have a mapping or something that returns the scaling factor for the given damagetype EDIT: switched over to an input damage type paradigm, which makes more sense anyway. TBD why I couldn't use TPair...

[mysterymagination]

todo: extracting from above, create Weapon and Armor classes that can be IAttacker and IDefenders so that we can effectively equip common weapons e.g. a claw to different primitive constructs like the treant's hands and feet. This way we can have common logic that just gets modified by params despite having to have different PrimitiveComponent subclasses.

• oh crivens, I went too far! Now I've mixed up all the anatomy and weapons and IAttackers in the refactoring and nothing makes sense anymore.
• todo: the join point with the engine is OnComponentHit event, which is a thing of UPrimitiveComponent subclasses and those and AActors are basically all the info we definitively have to work with at that point. That means we pretty much have to check for interface implementation and then go through an interface on one of those engine fellas to get into my overcomplicated realm of weapons and attacks and madness. SO. Since the Attack object has mostly subsumed the use of the IAttacker interface, I propose repurposing IAttacker to simply have a GetWeapon() function or something that then delves into the Weapon -> Attack behavior. Not sure where attack name string is going to come from, but that's a matter for AI later on.
• todo: as for IDefender, same as above but GetArmor() and then the Armor has a reckoning of what UAnatomyUnit it's equipped to and that will be taken into account in the received damage and debilitate logic.
  • weeeell actually maybe it doesn't make sense to have the UAnatomyUnit composite into a piece of armor; after all, if we create a WoodArmor instance, we wouldn't want to assume what body part it's attached to. Instead, the anatomy should likely be composited in the IDefender impl, and then we'll have a GetAnatomy() function in IDefender.
  • Nevermind, I already thought of this and made an IAnatomy interface. So I guess we'll have to check in the stricken UPrimitiveComponent subclass to see if it also implements IAnatomy and if found call through to its GetAnatomyUnit()'s Debilitate().

[mysterymagination]

Well most of the horrendous build errors I introduced with the refactor are sorted now... except I'm getting a bizarre linker error from anyone implementing IAttacker:

[2/3] Link UnrealEditor-Ryddelmyst.dylib
Undefined symbols for architecture x86_64:
  "vtable for UExtremityUnit", referenced from:
      void InternalConstructor<UExtremityUnit>(FObjectInitializer const&) in Module.Ryddelmyst.gen.1_of_3.cpp.o
      UExtremityUnit::UExtremityUnit(FVTableHelper&) in Module.Ryddelmyst.gen.1_of_3.cpp.o
      UExtremityUnit::UExtremityUnit(FVTableHelper&) in Module.Ryddelmyst.gen.1_of_3.cpp.o
      UExtremityUnit::__VTableCtorCaller(FVTableHelper&) in Module.Ryddelmyst.gen.1_of_3.cpp.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "vtable for UClawCapsuleComponent", referenced from:
      UClawCapsuleComponent::UClawCapsuleComponent() in Module.Ryddelmyst.cpp.o
      UClawCapsuleComponent::UClawCapsuleComponent(FVTableHelper&) in Module.Ryddelmyst.gen.1_of_3.cpp.o
      UClawCapsuleComponent::UClawCapsuleComponent(FVTableHelper&) in Module.Ryddelmyst.gen.1_of_3.cpp.o
      UClawCapsuleComponent::__VTableCtorCaller(FVTableHelper&) in Module.Ryddelmyst.gen.1_of_3.cpp.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

From what I can tell the IAttacker functions are all (both) implemented, so I don't know what the problem could be. I checked the generated code for the UClawCapsuleComponent class with a missing vtable and the generated code for IAttacker, and it looks ok AFAICS (basically I was just looking for the functions to be the new ones rather than the old ones for that interface, which they were. The rest was generated moonspeak.)

EDIT: I tried removing all the blueprint metadata crap and _Implementation rot from the equation and now things are fine. So the problem is somehow coming from that idiot dance they make you do on https://docs.unrealengine.com/5.0/en-US/interfaces-in-unreal-engine/

EDIT2: aHA!!! Turns out this crazy issue was caused by me duplicating the UFUNCTION metadata in both the interface definition and the implementation function declaration; you need the _Implementation fellas to not have a UFUNCTION macro above them at all apparently.

[mysterymagination]

Hmm, snowballs are not running their OnComponentHit delegate function EDIT: huh turns out you need a function to be decorated with a UFUNCTION() macro for it to work as a function pointer in a function delegate

[mysterymagination]

I added allowprivateaccess=true to the meta tag of armor and exunit props in ExtremityCapsuleComponent and for some reason now they are assignable in-editor, although without the pretty asset preview picture box... whatevs.

For future me, here is the tagging I used: For the UExtremityUnit class: UCLASS(EditInlineNew, Blueprintable, BlueprintType, meta = (DisplayName = "Extremity")) For the ExUnit and Armor properties: UPROPERTY(EditAnywhere, Instanced, BlueprintReadWrite, Category = "Combat", meta = (AllowPrivateAccess = "true")) and the props are TObjectPtr if that matters.

[mysterymagination]

todo: since the choice of attack event and the attack landing event are separate and async, we can't simply have IAttacker::ExecuteAttack() impls call Weapon::AttackMap["something"]->Attack::OnHit(). We need at least two stages, one in which the attack anim is kicked off and any other immediate effects happen, and then a second where a collision with the attack's associated physicality happens that then calls its OnHit.

• since this is going to be decided by the AI, the current decision should probably be cached in the AI itself rather than as e.g. a CurrentAttackName property in Weapon or something. That said, either works. I'll go with the Weapon CurrentAttackName approach for now since we have Weapon fleshed out already. Sure hope threading isn't an issue here because I have no idea how UE5 concurrency works.

[mysterymagination]

todo: bridge anatomy and armor such that armor knows what anatomy is under it; I want to have the armor on the head's impl of calcdmgrx multiply damage by a scaling factor, but I don't currently have any way for the armor function impls to know what anatomy is under them.

• for now I'm just going to have the UPrimitiveComponent subclass that implements IDefender and IAnatomy handle providing a pointer to the anatomy when its IAnatomy impl status is queried in Attack::OnHit(), and this anatomy pointer will be passed into Armor::CalculateDamageRx(). That way a given Armor instance doesn't need to be associated with any particular anatomy and our Form wrangling Function paradigm is kept intact.

[mysterymagination]

todo: implement WoodArmor

[mysterymagination]

todo: add UPrimitive subclasses with IDefender and IAnatomy impls to the Maya character

[mysterymagination]

todo: for some reason I'm not seeing Monster::OnHit() running for Maya's BodyCapsuleHitBox component, only for her CollisionCylinder

• unclear what's going on here. I tried all sorts of collision profiles, but none seemed to fix the problem.
• I added an OnComponentHit event to her body capsule with a print string attached, and apparently the boulder physics actor is registering her capsule colliding with it, but not anything on the treant.
  • the treant's collision cylinder also registers as being hit by her body capsule, so it seems like the issue is that the custom UPrimitives are getting ignored/are ignoring her body capsule collision checks for some reason?
• todo Do the Snowballs hit the different hit box UPrimitiveComponents on the treant? I'm curious if any of my custom hit box fellas are successfully on the receiving end of a collision. EDIT: yep
• I tried enabling physics for the respective skeletal meshes and also the relevant UPrimitiveComponents, and that crashes the game over my logging attempt in AMonster::OnHit(). So... possibly it caused more collision to occur, but also brought in some components that didn't appreciate being considered for my OnHit processing?
• I tried with the body capsule both socketed to Maya's skeleton and left unsocketed, and neither collides with our treant custom uprims.
• I tried making Maya's collision cylinder tiny in case the query collision needs to see her actual mesh making contact with something before a child urprim can receive collision data or something... it didn't help
• todo: create some other uprim guys on Maya and see if any show proper collision interaction with the treant custom uprims EDIT: nope, hers collide only with his collision cylinder and his only collide with her collision cylinder.
• I tried making both the custom uprim on Maya and one of the custom uprims on the treant huge so they should impact before the collision cylinders; didn't help.
• todo: try adding the Snowball collision sphere setup code (SetNotifyRigidBodyCollision(true) etc.) in the ctors of HeadBoxComponent (currently the largest test uprim on Maya and ClawCapsuleCollision (the debug 'claw' is the biggest uprim on the treant currently) EDIT: nuthin
• I noticed that firing the snowball now from effectively inside the giant Maya HeadBox leads to Snowball impacting same and damaging Maya, so collision between the Snowball and custom uprim on Maya works as well as Snowball and custom uprim on treant. So the issue is specifically about collision between the custom uprims themselves.
• I noticed that if I turn off collision entirely for the collision cylinder of Maya or treant, they fall through the level even though their custom uprims' collision should have prevented it.
• I put a clawcapsule on the woodenegg static mesh to see what would happen; it also doesn't register collision except with ACharacyer collision cylinders. When I made the egg's static mesh a physics actor (turn on simulate physics and make collision profile physics actor) however, the claw capsule collides with the ground and with Maya's HeadBox custom uprim component. I'm not sure what to make of that.
• tried adding OnComponentOverlapBegin/End events as well to Maya HeabBox and Treat DebugClawCapsuleRightLeg, to no avail. They register overlaps with distant static meshes and the like now, but not each other. Note, this is with BlockAllDynamic collision preset; might get different results with the overlap ones, but we don't actually want that. I was just hoping maybe the collision event was being skipped because the geometries overlap too quick and an overlap event would work better? It didn't. EDIT: ah wait, I forgot to enable generate overlap events during sim on the debugclawcapsule. Still nothing. EDIT2: finally, with collision preset OverlapAllDynamic on both Maya's head and body custom uprims and on the debugclawcapsule we see an attack successfully communicated for the first time! Too bad overlap doesn't really help. The stricken components, heabox and bodycapsule on Maya, can be either overlapalldynamic or blockalldynamic and this still 'works'.
• Tried adding child vanilla uprims to my custom ones and wiring up onhit for them, just in case. Didn't help.
• For sanity and simplicity, I created a barebones AActor blueprint with only the claw capsule as its scene root. That should help minimize variables as we see what it takes to get the damn thing to register collision with things other than ACharacter collision cylinders. EDIT: I have learned nothing new so far.
• todo: try enabling physics sim for all the custom uprims and see how terrible it is; we know that for some reason having physics enabled seems to help the collision event go through. EDIT: can't usefully do this since the editor crashes over a caught signal from AMonster::OnHit_Implementation(). Needta build debug so I can hit the breakpoint and see which thing is fucked.
• TODO: try making the snowball collision sphere be a custom uprim with the whole attacker/defender jazz goin' on. I wanted to do that anyway, and it will give me the chance to see if snowballs still collide with the treant's custom uprim anatomy even when their collision is totally defined by another custom uprim. If that works, then the structure of snowball and its collision config might help us figure out what is going wrong in interaction between custom uprims on ACharacters.

todo: maybe just put a pin in this shit for now; maybe it's a UE5 bug? Anyway, we can technically get along with what we have for the gameplay we want vis a vis multi-part natural weapon monster's attacks collide with the player's root cylinder and the player's projectiles collide with the monster's multi-part anatomy. The only thing we couldn't do is enable Maya's might high kicks to hit monster bits or for monsters to in-fight smashing bits upon other bits... but that's not really required for the main gameplay I had in mind.

[mysterymagination]

todo: create a subclass of UActorComponent that implements the common OnHit handling of the Clash API

[mysterymagination]

todo: calling ProcessCosts() in Cast() isn't always right because Cast() is not cast like cast a spell, but rather it's cast like cast a stone into a lake a.k.a. throw something. Some metamagic modifies spells so that we cast more than one bullet AActor per spell instance, and we should only be incurring the spell cost once, not per-bullet. It would be handy for this and for looking up metadata like spell casting cost and weighing against character MP before we go ahead with manifesting the spell to have a wrapper Spell class that contains the Snowball AActor and all its children plus some basic per-spell instance data and behavior like casting costs and processing those costs. The Attack object probably should stick to the Clash API stuff of delivering calculated damage to a defender etc. and leave the bookkeeping to something more abstract at a higher level.

• considering the fact we want a given snowball spell instance to be transient though and that Unreal makes it difficult to manually destroy UObjects, I think it might be best to just to remove the automatic call to ProcessCosts() from Cast() and leave it as the responsibility of the spellcaster/attacker to look up and process the attack costs when relevant.

[mysterymagination]

todo: ideally the ProcessCosts() function would take a callback listener (could be bolted on to BattleStatsBearer interface) that would inform e.g. RyddelmystCharacter that her MP stat had just changed by N so she can respond by updating her UI. EDIT: I just hooked up the UI to the battle stats

• although hang on a tic, isn't the UI already bound to observe variables somehow? Couldn't it just observe the BattleStats variables instead?

[mysterymagination]

todo: Snowball Clash API impl is almost complete, but the pipeline is broke somewhere because the Snowball AActors are not getting destroyed after collision, which should happen unconditionally in SnowballAttack::OnHit_Implementation(). EDIT: forgot to decorate OnHit in HitBoxerComponent with UFUNCTION, which causes it to silently fail as a ufunction delegate.

[mysterymagination]

todo: our UAttack::OnHit_Implementation() boilerplate code assumes the striking component's owner AActor is also a BattleStatsBearer, which is not the case in e.g. projectiles like Snowballs. For Snowball, we save a handle to the spellcaster that launched it, and that handle should be used as the BattleStatsBearer. How do we want to address this?

1. We could have cases like Snowball re-implement the boilerplate from UAttack::OnHit_Implementation() but with the appropriate thing in for BattleStatsBearer.
2. We could change the UAttack::OnHit_Implementation() API so that it takes a striking BattleStatsBearer param (may also want to do this for the stricken BattleStatsBearer).
   • May want to add a GetBattleStatsBearer() to IAttacker and IDefender so we can have HitBoxerComponent look that up for IAttacker and UAttack for IDefender to make sure we feed in the BattleStatsBearer AActor for each role in the exchange.

[mysterymagination]

todo: add impls of GetBattler() for applicable IAttacker and IDefender implementors, such as ClawCapsuleComponent and BP_ReaperTreantWoodArmor. TBD if we want/can add meaningful impls directly to the CPP or if it should be a BP thing.

• most cases are going to want to just return the owning actor, so I made that the default and SpellSphereComponent so far is the only exception.

[mysterymagination]

todo: wire up HitBoxerComponent in BP_ReaperTreant

[mysterymagination]

todo: now that Snowball implements the Clash API, what happens if we remove simulate physics on it?

• I no longer see collision with the other custom uprims (IDefenders), but I also don't see collision with the treant's collision cylinder; instead I see collision with the BP_Treant's CharacterMesh0.
  • The treant CharacterMesh0 had generate sim hit events turned on, but turning it off to match the config of BP_Maya's CharacterMesh0 didn't change anything.
  • Turning off generate sim hit and overlap on the treant's leg capsules didn't change anything either (was thinking maybe they were somehow too tied into physics?).

[mysterymagination]

todo: nevermind the query collision between my custom uprims; we only actually need snowballs (a physics actor) colliding with the treant's multiple hitboxes and the treant attacks to register against one thing (default collision cylinder) on Maya. So, we need to wire up the Clash API to Maya's collision cylinder and we should be good enough to go

• this will involve creating a dummy IDefender that the collision cylinder forwards collisions to
  • hmm, but don't we kinda need an IDefender to be the one receiving the hit in order for the attack to go off properly since we run the IDefender stuff directly through the boilerplate IAttacker flow that kicks an attack exchange off? sigh I guess that means we're adding a shim to the boilerplate UAttack::OnHit_Implementation() that does something different (forward attack and hit data to a bespoke function in Ryddelmystcharacter I guess) if the AActor owner of the collision cylinder is a ryddelmystcharacter.

[mysterymagination]

fixed in https://github.com/mysterymagination/ryddelmyst/commit/bf7c29fc2f03a2d462be7ad25804161f6a735758