Change parent ingame

I

Insanebrio

Guest
Hi everyone. I just need to know if its possible to change ingame the parent of a certain instance. Thanks.
 

jo-thijs

Member
No, but you can change the parent of an object by object_set_parent, though I very highly disrecommend you using that.
Why do you need to change parent objects anyway?
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
No. A parent is assigned to an object in the IDE and cannot be changed through code for an instance. You can change the object but it will only affect those NEW instances created afterwards, not those that exist currently.
 

GMWolf

aka fel666
No. A parent is assigned to an object in the IDE and cannot be changed through code for an instance. You can change the object but it will only affect those NEW instances created afterwards, not those that exist currently.
Will this work with the YYC too? Sounds like some rather inefficient stuff...
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Will this work with the YYC too? Sounds like some rather inefficient stuff...
It should, but I've not tested it... Can't say it's something I've ever needed to do, and having to use it would suggest to me that there is some flaw in your game logic.
 
F

fragment

Guest
I agree with the above posters. My guess is you really want something to have multiple parents.
I thought it was worth pointing out that a parent can have a parent.

Eg. in an rts you may have a range of objects for each unit

You have a obj_player_soldier
It could have obj_player_groundunit as the parent to show it is a ground unit
obj_player_ground unit could then have obj_player_unit as a parent to show it is a unit belonging to the player

The following code would then move all obj_player_soldiers (and all other objects inheriting from obj_player_unit) 1 pixel to the right:
with (obj_player_unit)
{
x+=1;
}
 

hippyman

Member
It should, but I've not tested it... Can't say it's something I've ever needed to do, and having to use it would suggest to me that there is some flaw in your game logic.
Carrying on from this. You should take a look at your parent-child relationships and ask if it makes sense. What I mean by this is ask if the child object "Is-A" vs "Has-A" parent object. For example, say you have a ParentEnemyObject. Then you make ChildEnemyObject. Now say, ChildEnemyObject "Is-A" ParentEnemyObject and say, ChildEnemyObject "Has-A" ParentEnemyObject. If "Is-A" makes sense, then you should make ParentEnemyObject the parent. If "Has-A" makes sense then you shouldn't inherit from ParentEnemyObject. You should instead contain an instance of ParentEnemyObject.

To further explain, say you have these three objects:
ParentEnemyObject
ChildEnemyObject
WeaponObject

ChildEnemyObject "Is-A" ParentEnemyObject

ChildEnemyObject "Has-A" WeaponObject

Hopefully that makes sense and helps somehow.
 

FrostyCat

Redemption Seeker
Repeat after me: Instances don't have parents, objects have parents.

If you want to inherit event behaviours, event_perform_object() can already do that.

If you want to group objects/instances by some property and act upon them, a with-if combo like this can easily handle it.
Code:
with (object_or_all) {
  if (insert_condition_or_property_here) {
    /* Actions */
  }
}
Many novices around here want the ability for objects to have multiple parents or change them at runtime. None actually needs it.
 

GMWolf

aka fel666
If we can change the inheritance at run time, this means it is not optimized at compile time...
Should we ask to make this (I suspect) little used functionality obsolete to allow for better optimization?
Not to mention it is quite bad form...
 

NightFrost

Member
I have only once ran into situation where multiple parenting would have been nice to have: collision detection on movement. In the game player and enemy objects largely tested movement against same objects, but there were a few, mainly force walls, that let enemies freely through but stopped players. It would have been nice to have been able to collate everything under a single collision detection groups of "players check against all these children" and "enemies check against all these children." Instead, several collision checks were necessary. But this mostly falls into "pretty code" category.
 

GMWolf

aka fel666
The problem with multiple inheritance is choosing what methods get inherited.
Simply saying the object would inherit from first/last parent is not enough; what if you need to inherit from both orders?
 
Top