Spawn Despawn Objects: Any Problems with Getting Instance id Numbers Too High Over Time?

Discussion in 'Programming' started by 2d_warrior, Jan 9, 2019.

  1. 2d_warrior

    2d_warrior Member

    Joined:
    Jul 14, 2016
    Posts:
    159
    If you continually create and destroy many instances quickly (meaning there's never too many at once), what happens if this is done for a very long time in one room? Do higher and higher id numbers cause any performance hit, or crash over hours? Does the id number eventually wrap around? Are there any problems with frequent spawning and despawning of objects in a room without any time limit, or is that perfectly fine?
     
  2. TheouAegis

    TheouAegis Member

    Joined:
    Jul 3, 2016
    Posts:
    5,922
    It wraps around, but good luck getting there.
     
  3. 2d_warrior

    2d_warrior Member

    Joined:
    Jul 14, 2016
    Posts:
    159
    Ok. So high ids won't cause any performance problems, or crashes? Just want to be sure a spawn/despawn system wouldn't crash over unlimited time in one room.
     
  4. Jabbers

    Jabbers Member

    Joined:
    Jun 21, 2016
    Posts:
    204
    A post from 2016 suggests that things can start getting funky if you reach 100,000 objects in a room, because IDs will overlap with instance IDs. Presumably you would need 100,000 instances running simultaneously for this to be an issue. I don't know enough about this problem (or if it even applies in GMS2) to comment further, but I thought it was relevant.
     
  5. TheouAegis

    TheouAegis Member

    Joined:
    Jul 3, 2016
    Posts:
    5,922
    Correction. You don't need 100,000 objects in the room, you just need to create more than 100,000 objects in the project. In GM8, this would be lethal to the program potentially. In GM:S, you'd have to actually have more than 100,000 objects in the project. It doesn't matter how many instances you have in a room, just how many objects are in the resource tree.

    You could always use instance_change(). Although it I guess keep track of variables so that may or may not cause memory bloat, but it shouldn't be too big of an issue. But no, you shouldn't worry about it too much. If it crashes, shame on the player for playing that long without a break. lol
     
    2d_warrior likes this.
  6. 2d_warrior

    2d_warrior Member

    Joined:
    Jul 14, 2016
    Posts:
    159
    Great! It shouldn't be a problem for me then. I don't think I'll be putting 100,000 objects in my resource tree, or a room.

    I have managed to get the resource tree generated object names above 6,000, but that's because I'd merged with another game file and the actual number of objects in the tree was probably less than 2,000. This was in GM 5 and the collision events stopped showing up as events, if they involved the newly added objects (think it happened around number 4000), when I close the object editor, and reopened it. The events still existed and you could see them if you added the event again. Don't know if that's an issue beyond version 5 though. I found a workaround of sorts on that project, but it shouldn't affect this one anyway.
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice