It’s probably my 5th version and also the best working one so far. Now I believe the only issue is that sometimes… very rarely… they dont get their speed back when they stepped out of the trap. So its not 100% working. I tried to solve that with the delay at the end of collision, to make sure they are not touching anything else anymore
The big problem here is probably the collision and that I dont want to use tick. Since the enemy can be affected by one trap, then if there is a trap just right next to it, he overlapps with the second trap (while still affected by the first one) then at somepoint not affected anymore by the first one but already missed the first checks of the first collision entry.
Here you can see the critical points. If they move right in the middle of them and touching all traps. Or the moment when they just enter the next trap while still touching the last one.
I really like using actor components for things like that - think of it as a highly modular temporary (or permanent) buff / debuff system, where one can grant actors an extra ability. In case of a trap, the *ability *would be deducting health over time and remove itself from the affected actor once expired. And you don’t need to Tick or Delay anything - up to you, of course.
Consider the following, we have 3 elements at play:
When the trap overlaps something, we check whether whatever stepped in is already affected by this trap’s effect (I believe you want to avoid multiple traps affecting a single entity). If this kind of trap effect is not affecting the target, we create one.
and the **Trap Effect **itself, the aforementioned actor component. This one deals damage over time:
When a trap creates an effect on a Monster, we start the timer. When the timer executes the Damage Event we increase* Trigger Count.* Then we deal *Damage (*set via a variable exposed to the **Trap **in pic 2) to the owner (whoever stepped in). Finally we check how times this trap has bled its target - if the threshold is met, this component will remove itself from the owning actor. If the owner gets destroyed, they will take this component down with them, too.
vid: https://i.gyazo.com/c198dc461cf6c602…94344ba8bb.mp4 [HR][/HR]
The above is a not a full system, of course. It’s an idea that worked well for me and I believe is worth exploring. It’s quite modular, somewhat easy to maintain and, once combined with inheritance and interfaces, gives you a great deal of flexibility.
Yes thats the most obvious choice and probably one of my first tries (If I understood you correctly). But then you realize you run into trouble when the trap is not repeaditly asking. Why:
Enemy steps into his first slow trap.
Slow trap asks if it shall activate slow on him
Everything works as intended
But then he steps into his second trap while he is still touching the first one as well and thus is still affected)
The second trap then asks, is he already affected? Oh yeah? Well then I dont apply slow.
A few milliseconds later the Enemy **is now no longer touching the first one = **base walk speed is applied again (no slow anymore)
Now he is still walking on the second trap, but the second trap already asked and therefore no new slow is gonna be applied.
Hope this makes more sense now. I tried to show this in the video etc.
Maybe you have some more suggestions?
Oh hi again Anything to say about my Tar/Slow Trap 3D asset? haha
I’m still studying your reply!
Some of your post makes absolutely sense to me, for example I made an “Arrow Trap”, so a damage dealing type, kinda like you suggested.
One thing: You mentioned that all of this is obviously not a full system, but that makes me wonder: This “is valid” node in the 2.pic. Is it working on its own? Without further branches etc.? And if its working on its own and checking something, what is is checking? I mean, obvisously if its valid. But what is valid? Haha I am sorry for my gibberish writing.
Regarding pic 3: Thats probably the half I understand the least. I mean…I have ideas on where this could work really nice, on other traps. But for this slowing one I would need to know how long it takes him to cross the trap, right? If I want him to only be slowed while he is touching the trap.
I kinda tried to avoid such thing because it sounds like manually data input
I honestly need to study your text a few times more, maybe I just didnt understood the potential for my current issue yet.
How I would do this is when the component begins overlapping then start using your timer on it, but save your timer handle (it’s the only return on the timer) to some variable.
Now, when the component stops overlapping, (there is an event for this) then you simply invalidate and clear the timer handle you saved. You want to do it slowly? That’s find too, just do it when it stops overlapping.
Your main problem is that you started a timer and you never stop it.
Anything to say about my Tar/Slow Trap 3D asset? haha