Units not appearing after a crash

Discussion in 'Mac and Linux' started by themine12, September 27, 2013.

  1. themine12

    themine12 New Member

    Messages:
    23
    Likes Received:
    1
    So my game crashed while ingame, then when I joined in again only some units/buildings appeared (most to all enemy buildings/units were there) is there anything I can do to solve this?
  2. UberWilliam

    UberWilliam Uber Alumni

    Messages:
    28
    Likes Received:
    76
    Yes. Hit home, then end, then close chronocam. Your buildings should reappear.

    Turns out some improvements to the history server we made for the beta didn't come out completely bug free. In order to blow a big crater in the side of a planet, we need to clear out the trees. Trees floating in space above the big crater kinda ruin the experience a bit. So we converted trees from being static initialization data to being actual entities in the simulation. That way, the simulation could say "remove these tress and light those trees on fire" (the lighting on fire is still WIP, but planned).

    But it turns out there are a lot of trees. Like several orders of magnitude more than anything else. 20k trees on a planet isn't uncommon and I've seen planets with 140k trees. Before this, we were updating a thousand or two entities in a big game. Now we need to handle 140k? Luckily the history system already only sent deltas, so there was no additional bandwidth spent updating the 140k trees that didn't move, shoot, etc. But the server was still looping over all the entities trying to find units to update among all the trees.

    I had always planned on doing something smarter than "loop over all entities that have ever existed and check to see if they change changed in the last 0.1 seconds" over and over. But it turns on that modern computers are fast, and that dumb loop wasn't slowing anything down. So bigger fish kept getting fried.

    The addition of the 140k trees caused that code to choke. The improved version is a bit more complex. Basically we keep 3 lists for each client's point of view in time:
    • all entities that changed in the past sorted by the last time something changed.
    • all entities that will change in the future sorted by the next time something changes.
    • all entities that we know need an update but we haven't been able to update yet, sorted by last update time.
    Then when we go to update a client, we:
    • pull entities off of the past or future list depending on whether the client is playing forward or rewinding and add them to the update list
    • send as many entity updates from the update list as bandwidth allows, adding them back to the past and future lists based on the updated client time.
    Entities that don't change much (like trees, or even power generators) quickly have their entire history sent to the client. And as long as they never change, they never get pulled off of the past or future list (or even put on the list), so they don't cost any additional cycles. 140k quiescent trees, no problem!

    Except there appears to be a bug somewhere.

    -William
    Remy561, exterminans, Raevn and 12 others like this.
  3. o

    o Head Honcho Official PA

    Messages:
    132
    Likes Received:
    39
    Everyone should like this post even though he answered the question in the first sentence.
    Remy561 likes this.

Share This Page