I would like to manage to do some kind of dissolving blocks for my platformer. But the way i made it doesnt work the way it should.I made an array of sprites that forms my “tilemap” and added those sprites into an array.Then on the tick event for each sprite in the array to destroy it. Without delay, it works and destroy the block that i’m touching, but if i add a delay it destroys the block that i overlap after the delay not the one that i was on. Not sure if i explained properly what i want to achive so i post a short video to understand better.
Your BeginPlay section could be moved to the constructor but seems to work fine, I took a look at the second part. You dont really need the Tick but the issue seems to be begining On Hit Component, it doesnt seem to be called in my quick test. What I did is instead bound On Actor Hit and selected the component from the Hit Result, cool.
Youre probably doing something more specific in your BP that I cant replicate exactly. I can see why youre having an issue and I think a list of Timer Handles could solve it by keeping a record of each countdown.
What I think would be a better solution is to use a BP that encapsulates the individual sprites and then you can put the delay within the Actor itself.
This is what I got and it works, it stores an array of each time youve touched a block and is associative to the mesh array. I do not remove meshes (sprites in your case) from the array because of this so you may need additional checks for accessed nones but it works.
Ideally though the engine should have a delay on destroying Actors/Components, I think that would be most performant and safe in regards to access.
It works, there’s only one thing. It destroy the block on hit, it should destroy it on overlap aswell, because my character can wallslide, and when he goes down i want all the blocks that he collides with to be destroyed, and it doesnt work with Hit Event, but the Overlap Event obviously doesnt have “hit” node.Any ideas how i could do it on the wallslide?
I would strongly suggest using individual actors for each tile instead of one blueprint for a whole wall.
That way you can easily use Delays, overlaps, hits however you please without worrying about much with much easier and better control.
The original solution wasn’t working because you’d call “Delay” multiple times. However delay will just run down and then act. All other inputs that reach “Delay” will be ignored.
You also do not need to set the EventBinding on each tick. You can just call it once at the beginning. Using this method means that you will have to rely on event tick or similar things which is generally not desirable.
With individual actors, event calls and delay you are completely event driven, have better control over placement and don’t need such a complex script for this rather simple task. It is overall a much easier and cleaner solution. And if you’re annoyed by placing so many boxes, you can write your own spawnerscript that takes care of that!
Well I couldnt get the overlap event binding working but as you have shown it seems to work on yours. You can do it that way then instead of OnHit like Ive used you use your binding to do the same thing instead.You shouldnt have to set the event bindings on tick so you could try moving that to BeginPlay too.
As I said though and as Erasio is saying Actors could possibly be a better option than running complex script, you get to a point where the performance savings will be negligable because of the extra overhead of dealing with components.
I do think there are some improvements that could be made on the component end but I wouldnt rely on anything happening too soon.
An option instead of destroy might be to simply just hide the component rather than sending it through to garbage collection. Large arrays would be bad for performance too so Im not sure how many of these you plan to use. Id be careful about over optimizing though especially before youve tested performance. I will say Actor destroy calls are certainly fairly weighty vs a Components.
It’s a minor strain on RAM, and not at all impacting CPU. The ticking method is worse CPU wise and a bit better RAM wise.
You still have multiple components. So rendering wise it’s the same, collision is the same. All overhead is the RAM footprint of the actor (aka the list of variables every actor comes with. That is minimal).
And you wouldn’t tick it at all with that method meaning every frame is better because you are not running any code at all unless it’s invoked by something else.
