Jump to content
  • Advertisement
Sign in to follow this  
lucky6969b

Component stays alive when the GameObject goes out of scope

This topic is 770 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've got a component manager that stores a reference to the component,

this component is created as a new instance or obtained thru a singleton.

and data type for it is boost::shared_ptr.

void Truck::Create()
{
    SimObject::Create();    

    boost::shared_ptr<Arrivals> l_arrival = Arrivals::getInstance();
    this->AddComponent(ComponentManager::getInstance()->AddComponent(l_arrival));
    
    CMinMax<float> arrivalTime(10000.0f, 20000.0f);
    this->FindCompoentByType<Arrivals>()->PostRequest(*this, arrivalTime.GetRandomNumber(), arrivalTime.GetRandomNumber());

When the component is first created, the strong count is 4,

1st from the getInstance itself

2nd from l_arrival

3rd from ComponentManager::getInstance()->AddComponent(l_arrival)

4th from this->AddComponent();

 

which is quite strongly referenced.

When the game exits, the game object dies,but the component stays alive,

the arrival component is basically an observable by the game object (the truck),

the truck dies, the observable has no observers to deliver messages to,

so the program crashes.

 

I like the idea of self-managed pointers, but it seems not applies here

 

Also the arrivals component has a threadpool in itself,

but the destructor of arrivals is too late to destruct, when it dies, all pending requests will be purged.

 

Any better idea for me?

Thanks

Jack

Edited by lucky6969b

Share this post


Link to post
Share on other sites
Advertisement

When the game object store a shared instance of the physics mover,

I am wondering, if the game object uses a unique_ptr to store components,

in order to keep the interface consistent, should I make up 2 separate kinds of components,

one sharable to be used by components like astar, timeastar and physics

and non-sharable (solely owned) by one object, like the state machines?

the common data type is a Component, so that I can add sharable and non-sharable

components to the same container?

 

The only problem is when the container is a unique_ptr, it is not sharable in the first place....

// Step 2 ---- should be a singleton, shared by many objects
PhysicsMover* l_physicsmover = PhysicsMover::getInstance();    
l_physicsmover->addMesh(this);
this->AddComponent(ComponentManager::getInstance()->AddComponent(l_physicsmover));   
Edited by lucky6969b

Share this post


Link to post
Share on other sites

Sorry I haven't responded, I've been AFK a few days.

 

First, to answer your question: unique_ptr is just a convenient way to automatically delete objects when the pointer goes out of scope, but it is not essential to use it. You can just store raw pointers and delete the objects at the appropriate time (e.g. in the game object destructor). You would need to determine which components you own and should delete, and which components are shared. Even though it's technically possible however, I would not mix objects with different ownership together in one container, seems like asking for trouble.

 

Second, I will ask some questions of my own if you don't mind. Why is PhysicsMover a shared singleton? If it makes sense for it to be a singleton, should it even be a component? Maybe it should be a subsystem (that acts on components) instead? Astar doesn't really seem like a component to me. If you have a single shared Astar component, where would the calculated path be even stored? How about a Pathfinder component instead, which can have parameters like pathfinding speed vs. accuracy, and uses the Astar subsystem (or can use any associated pathfinding system) to calculate paths that it can store?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!