Destroying component invalidating function pointers?

[MokaHiko]

I'm trying to destroy projectile and instantiate particle effect entities on the same collision callback. Both entities have "Script" components that have lambdas to handle construction and destruction of said scripts. The lambdas use script identifiers stored in the Script component to decide what to instantiate. The identifier for the particle effect seems to disappears when using the construction lambda after destroying the projectile entity.

[skypjack]

It's really hard to help without a repro. It can be anything, literally. I barely get what you're trying to do from the description.
Is there any chance that you can provide a minimal, reproducible example or something that gets closer to it at least?

[MokaHiko]

Hi! Thanks for replying. I'm a big fan. Here's some snippets that hopefully clears things up.

Here's the definition of my Script component that's a wrapper for a ScriptableEntity script

struct Script
{
    ScriptableEntity *script = nullptr;
    uint32_t binding = {};

    std::function<ScriptableEntity *()> InstantiateScript = nullptr;
    ...

    // The member function that assigns the bindings 
    template<typenename T>
    void Bind()
    {
        binding = GenerateBindingId<T>();

        // The member function that is called to instantiate a script  
        InstantiateScript = [this]() 
        {
                auto& it = script_instantiation_bindings.find(binding);
                assert(it != script_instantiation_bindings.end() && "Script binding not registerd!");

                return static_cast<ScriptableEntity *>((it->second)());
         };
        ...            
     }

     // Where I store the instantiation functions 
     static std::unordered_map <uint32_t , std::function<ScriptableEntity* ()>> script_instantiation_bindings;
 }

This is in the script's OnCollisionEnterFunction().

• It Queues up the "Collision Particles" entity with a Effect script for creation in the next update loop.
• Then Queues itself up to be destroyed (the Projectile script gets destroyed before the Effect script is instantiated)

Entity collision_effect = Insantiate("Collision Particles");
...

auto &script_component = collision_effect.AddComponent<Script>();
script_component.Bind<Effect>();
...
QueueDestroy();

Here's pseudo on how the scripting system flows

if(Script Not Yet Instantiated )
{
      // At this point Script.binding is still correct
      // Inside the InstantateScript lambda is where script.binding becomes a null or the default value 
      // Which only happens when I destroyed projectile last loop 
      Script.script = Script.InstantiateScript(); 
}

for(Entities With Scripts)
{
   Update(); 
}

//Where the projectile is destroyed
FlushDestructionQueue(); 

My best guess is that the problem is to do with how I destroy and create entities. After destroying an entity I keep the ID to be reused for the next call to registry.Create(). This is because I've been using entt ids as indices into buffers for my rendering so I need them to be in a reasonable range (Idk if is a good idea)

[skypjack]

I see. Well, this is risky at first glance and most likely your problem too:

InstantiateScript = [this]() 
        {

You're capturing this, the address of the component assigned to the entity, is it?
In this case, keep in mind that components are moved within a pool to optimize performance iterations. Unless you tell EnTT not to do that ofc, since everything is configurable here. 🙂
If you want stable pointers for your component type, add the following to your Script class:

static constexpr auto in_place_delete = true;

In this case, this is never invalidated until you destroy the component itself.

Another option is to make the instantiation function static and pass the script to it as an argument.
I can provide you an example but I think it's easy enough if you get what I mean.

As for your last comment, that's an option but it can easily fail if you generate other entities in the meantime and the identifier is recycled before you have a chance to reuse it.
Instead, the in-place delete policy would solve this issue out of the box without the need of recycling the entity identifiers. In this case, when you erase an entity, a hole is created in the storage. This hole is then the first slot to get reused when you emplace a new element.
This means that you can do something like this to have the right index from a packed set to use with your buffers:

const std::size_t idx = registry.storage<Script>().index(entt);

Nice, isn't it? 🙂

[MokaHiko]

That really helps. I think I'll go with making instantiation static. That way I can maybe cache hot scripts that are frequently created and destroyed. The in place delete is really neat. I didn't think about those cases but I had a feeling my solution was far from fool proof.

Thanks again!