You clearly have a mechanizm that repositions or respawns them. Perhaps something is delayed? Some of them don’t even have any text displayed (my eyes may fail me), perhaps you could share more details regarding how this is handled. The whole reset.
Pretty impossible for me to guess.
if every hunter does this:
And still shows anything else than 0, then there is something else going on that we do not know about. Perhaps there’s a rogue delay node, perhaps the hunter lands on an apple as we restart. Perhaps a tick event sets something to the wrong value. That’s why updating things on tick is so cumbersome to debug.
You Print Generation Completed but this is the script that fires when an apple is eaten. Probably irrelevant on its own but who knows what else is attached to it.
This whole thing below belongs in the hunter and should be encapsulated. It’s the hunter that keeps track of the apples they’ve gathered - they’re already doing it here:
It’s the hunter that spawns the offspring. You can always communicate the results to the managing actor, for tracking purposes. Considerer refactoring it.
It’s also not set up correctly. You fire the completed pin - this means you only apply the script to the last element in the array. This loops also destroy actors, so this is catastrophic and will eventually crash when you attempt to access a non-existing hunter.
Yes I thought that if the level blueprint and the actor blueprint are gonna communicate either way I might aswell give the level blueprint its own check-if-hunter-should-be-alive-system to make it easier for me
Is it possible to do array elem after the destroy actor? maybe that will hold it off from ever checking that specifc array element?
Not 100% sure if I follow. What I meant is there is no reason to loop through all the hunters to see whether they are ready to do something. Have the hunters report to the LB when they’re done with their task - each hunter does its own thing, for example:
a hunter will tell the LB it’s done with gather via an Event Dispatcher:
You can pipe in any kind of data or a self reference and the LB can pull what it needs from the actor and then destroy it.
This will fire only once and only when the hunter has done their work. Not sure if it’s needed but if you’re planning to have a managing actor (a great idea 99.9% of the time), that’s probably the most efficient way of communicating. Definitely the most performant one.
Alternatively:
You may opt not to destroy the hunter. You can hide it and only destroy it once you’re really done with it. Or, better, never destroy it, hide it and reuse it - that’s pooling.
Adds to the complexity but if the goal is to have thousands, it’s worth looking into.
I tried doing this, I think it works good enough? Im unsure since I havent tested more. hunters with value below 1 die now, hunters with value of 1 does nothing and hunters with value of 2 adds to the offspring.
I have thought about that before, Ill try reusing once im done fixing all the wrongs in the blueprint so I can make sure that I atleast have a backup-picture of how the code is supposed to work.
So the intended logic is that we destroy the underperforming hunters, right? Then this binding makes little sense in this context. It was more of an example of how they can communicate with the LB.
Also, shouldn’t the offspring variable belong to the successful hunter so they can spawn them? Not sure how you want it to work - might be fine as is.
When it comes to the error. Seems like you have an array somewhere populated with hunters and you attempt to call it to manipulate actors that have been destroyed.
Destroying an actor does not remove its reference from an array. So you either need to remove the indexes, check isValid or rely on Get All Actors of Class instead - it will never pick up anything that is pending kill.
Well since I only know how to use spawn actor within level blueprint Im sure I can just collect the value-properties of the hunter that performed well and alter them to the offspring all inside the level blueprint
Fixed it! Its now removing the index
Heres a video on how everything is working right now:
Some still end up having 1 apples found even after reset
Offcourse I see that apples cant be collected since some hunters take up space but its not a big deal since you could just add a time-limit for all the hunters
May work well, may be cumbersome - really depends on how the offspring system works and how much processing is needed. For example - things may get iffy with this approach if the offspring need to inherit something from the parent who no longer exists.
since I only know how to use spawn actor within level blueprint Im sure I can just collect the value-properties of the hunter that performed well and alter them to the offspring all inside the level blueprint
You probably could but why complicate things, restarting the hunter may spawn new offspring hunters:
I followed your example but I saw that the ones that only ate 1 apple also died because 1 !>= 2. So I did a switch case to have something to make sure that the ones that only managed to eat 1 stay alive but do not create offsprings.
Here are the runtime errors im facing:
I assume these are because of those hunters that fail to restart their score. Some still reset with 1 apple in their stomach which is not what its intended to be.
@Everynone Hi again!
I FIXED IT
I noticed that the apple was destroyed before it could add to the score which would set off an error due to it not existing
I then later found out that the for loop to reproduce did more than 1 time n’ so I did a if statement instead of a for loop since it worked better!
Im all done now, I feel like learned much about blueprint now and thank you for not responding at all in the end. It made me think more for myself!
n’ so I did a if statement instead of a for loop since it worked better!