You are not logged in.
Pages: 1
Persistent object instances deactivated in one room can not be reactivated in another.
Abusing forum power since 1986.
Offline
I hope Mark takes a look at this website to see all he's missed.
Offline
Brief Description: instance_activate_* functions - do not work on a persistent object instance that was deactivated in another room
GM Versions: GM5, GM6, GM7
References: [1]
Example File: http://www.planetxot.com/download/persi … te_bug.gmd
Bug Confirmed: Yes
Hardware Dependent: No
Main Info:
If you deactivate a persistent object you can not re-activate it in a different room (however it can be re-activated with a persistent room when re-entering the same room). This behaviour has a high potential for memory leaks.
Workaround:
It is probably easiest just to not use persistent objects when wanting to do this. A way of dealing with it though is to store all the id's of persistent instances in a data structure when you deactivate them. Then whenever you change rooms activate all the persistent instances from the data structure and in the creation of the next room deactivate all the instances again from the data structure.
Last edited by flexaplex (2009-06-14 14:36:39)
Offline
Here are some more details and a demonstration.
Persistent object instances deactivated in one room can not be reactivated in another.
Once the room change has been made, the instances can generally never be reactivated. However, instances deactivated in a persistant room can be reactivated in that same room upon reentering (this is of course true of non-persistant instances as well).
The behavior seems consistent for Game Maker version 5, 6, and 7. I've only tested the instance_de/activate_object()
functions. I'm assuming the others behave the same as this appears to be an architecture problem. This should be verified, of course. This behavior has a high potential for memory leaks.
Abusing forum power since 1986.
Offline
Ok updated the post. I can confirm it occurs with the other instance_activate_* functions.
Offline
Ok updated the post. I can confirm it occurs with the other instance_activate_* functions.
Thanks for checking.
Then upon changing rooms ever activate all the persistent instances from the data structure and in the creation of the next room deactivate all the instances again from the data structure.
In that sentence, should "ever" be "always" (or simply removed)?
Abusing forum power since 1986.
Offline
In that sentence, should "ever" be "always" (or simply removed)?
It was supposed to be in the context 'when ever you change rooms", I've changed it now.
I think I have completed a template for all the bug topics already posted here now, except the ds_grid_set_grid_region topic which hasn't got an example file yet.
Last edited by flexaplex (2009-06-14 14:39:02)
Offline
I guess I need to get busy moving topics. The ds_grid_set_grid_region()
problem is a weird one. I need to do more investigation of exactly how and when it fails.
Abusing forum power since 1986.
Offline
I guess I need to get busy moving topics. The
ds_grid_set_grid_region()
problem is a weird one. I need to do more investigation of exactly how and when it fails.
Lol I ran into it again once more (wanted to use someone else's code which contained -although a bit hidden- this function).. Didn't you discover something along the lines like "every call the accessible data reduces by 1"?
Offline
Yeah, if I remember correctly, it seemed that the number of processed rows got shorter and shorter each time the function call was repeated for the same grid. I think I was trying to sort the rows of a grid by column. Weren't you trying the same thing when you found it? As I recall, we both found it independently on the same day, and doing the same thing.
Abusing forum power since 1986.
Offline
Pages: 1