Parenting issue

I know it's a brief title but it's pretty much the problem I have. I read this article which says about nothing about how it works bisides the fact that it's a good idea: https://docs.yoyogames.com/source/dadiospice/001_advanced use/more about objects/parents.html
https://docs.yoyogames.com/source/dadiospice/001_advanced%20use/more%20about%20objects/parents.html
So, being convinced in the doc that parenting is a nice practice and usefull, I tried to use it. But nope... Nothing happens on my side. I won;t be posting the project as it will be release on the marketplace but here is a detailed explanation on the situation.

• First object - call it "obj_coin", has a creation script, a destroy script and a step event script.
• Second object - call it "obj_life" has absolutely nothing in it because it shares all the scripts of obj_coin SO instead of copying the code AGAIN from obj_coin, well, I decided to say that it's parent is obj_coin.

I hope you are following for now because I'm almost done...

When running the game, obj_life does not run anything. Why? Did I miss something? I mean, I have absolutely nothing different in obj_life and obj_coin besides how the player interacts with them, the rest is identical.

I tried to do a step by step runnin with the extremely long "F11" procedures of GMS debugging. I added a script call in obj_coin's create event for example scr_do_something("some text"). In the scr_do_something script, there is one single line: var some_text = argument0;

I put in the room ONLY one obj_life and put a break point on the 1 line on the script. Results ---- The game never pauses because it never runs the script. Did I not understand how parenting works, I may have missed something?
 
does the child object's events have even empty scripts in them? If so then you will need to delete them or else put event_inherited() in the script.

have you verified that the code in obj_coin works if you put an instance of obj_coin in the room?
 
The code DOES work in obj_coin without any issues and perfectly. As for the child object: obj_life, There are absolutely NO events or scripts. It's basically an empty object with only the parent option selected to be obj_coin.
 

Genetix

Member
So obj_life is a child of obj_coin is that correct? A child will not automatically run the code of it's parent, you have to tell it to do so. For example if your parent has a few lines of code in the Create Event, then in the childs create event you need to say event_inherited() to run the parents Create Event code. This allows you to have children that don't always run specific events of their parents, and also able to run their own unique code with the parent code.

Best thing to do is keep experimenting with it until it starts to make more sense, good luck!
 
So obj_life is a child of obj_coin is that correct?
Yes, that's correct.

A child will not automatically run the code of it's parent, you have to tell it to do so. For example if your parent has a few lines of code in the Create Event, then in the childs create event you need to say event_inherited() to run the parents Create Event code.
Well, that's what I did NOT want to do. I expected the code to run normally from the parent if we do not do anything but if I entered code manually in the event, then it would override that of it's parent UNLESS we call the event_inherit(), in which case it would ALSO execute it's parent code.

I'm a bit decieved by this functionality as if I add an event in the parent object, I'll need to open up every single other child objects and add the event with the event_inherited() code. So if I have 10 different object that behave the same, might as well create a script and make them all run THAT script, its the same thing besides the collision event with other objects which will need to be programmed individually. I would have expected a bit more from this function. That was my first time using parents as I never really needed parenting because I was using common scripts instead.

Best thing to do is keep experimenting with it until it starts to make more sense, good luck!
I added every event manually in my child object and added the built-in GMS drag-n-drop inherit event action. And the code worked like a charm. As I said, I'm somewhat decieved that we need to add the events manually for every single child objects.

Thank you for your response, I'm glad to have sorted this thing out even though it does not go the way I hoped
 

Genetix

Member
Yeah, I'm not sure you have to call event_inherited() at all if the child doesn't use an event that the parent does, have to look into that. Parenting does work a bit differently then just running a script for all objects however. For example, you can perform collision checks on a parent object and they will also check for any children of that parent I believe, along with a few other things. I still learn new things almost everyday after spending over a decade with Game Maker, keep at it!
 
Parenting does work a bit differently then just running a script for all objects however. For example, you can perform collision checks on a parent object and they will also check for any children of that parent I believe, along with a few other things.
That, I already knew. What I didn't is that you needed to cal the inherit parent action for every single event. I would have liked a function that calls the enherit event for the whole object and not call it for every event. It would have been more practical.
 
J

JFitch

Guest
You shouldn't have to use event_inherited if there is nothing in your event. It should assume that. I have a game that uses parents and the event works when nothing is stated in the event. The problem may be something else.
 
You shouldn't have to use event_inherited if there is nothing in your event. It should assume that. I have a game that uses parents and the event works when nothing is stated in the event. The problem may be something else.
Well that's special.... I just deleted all my events in my child object and the system decided to work.... That's awkward as that is the exact same configuration I had before posting this thread and it did not work initially..
 
F

frumple

Guest
If a child doesn't have a Create Event but the parent does, the child will perform the parent's Create Event.
If a child has a Create Event, it will perform it's Create Event regardless of wheter the parent has one or not.
If two objects have a Create Event which is 99% identical but you wish avoid having the duplicate code, you can make one the parent of the other, then in the child's Create Event you call event_inherited to run the 99% and after that add the remaining 1% that is unique.

This is true for all events not just Create. As an example, you can have a whole group of different objects be children of one empty object save for User Event 0. If you call that event using with (parent), all children will perform it. Parenting is not neccessarily about hierarchy. Sometimes it's the convenience and having an ability to perform code that affects a lot of instances without neccesairly giving a monkey's about their instance IDs. Sometimes the child is the less complex object, but it can be the other way around. What if you wanted several objects to react to the right mouse button? You could give each the global right button event, or you could make them children of an object that has nothing but the global right button event. They would all use their own Create, Step, Draw and other defined events, and all would react to the RMB being pressed. I'm not saying it's a great example, i'm saying that's one way to use inheritance to group together objects that otherwise have little in common that you still want to share some code.

The question is wheter or not it is a good idea to allways try to use it because it is recommended as something usefull. I'd say no. Stick to the simplest solution you can think of and implement inheritance when you spot a use or need for it.
 
A

AliceBallaster

Guest
Note: I find having a different collision mask for an inherited object does weird stuff. No clue why.
Even with zero new code in your derived [object/class],something weird happens with collision logic
if you specify a different collision mask.

Specifically, my derived objects drilling themselves into surfaces they should be standing on.
But I am sure the weirdness for me will be different than whatever it is for you.

I don't claim to know what I am doing. But this fixed my problem after looking at all the code and
realizing the problem wasn't the code.
 
Top