Your Props Might Disappear

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Your Props Might Disappear

    Currently I am experimenting with ways to reduce server uptime in a manner that does not involve clearing props out of the database.

    This involves having a set of global props that are always loaded while also loading and unloading player props. This will reduce the entity count and hopefully result in an uptime increase.
    Your furniture might not load, may act odd, or will do odd stuff as I look at the errors and fix it. Global props seem to have been loading without problem. It's mainly just player props that aren't loading right.

    Admins may look at the main door of an apartment and use the command: /loaddoorfurniture to load the props associated with that door. /unloaddoorfurniture can also be used to unload furniture linked to a door. The plugin might tell you that the props for a door are already loaded. If it does, just do /unloaddoorfurniture and then /loaddoorfurniture. The props should then spawn.

    Also with the help of Syle, I have identified the specific code paths leading to the "memory leak" issue. Now I know exactly how to fix it. This will take me a day or two. The above two fixes should bring server uptime from the 5-12hr range to the 1-2 day range.
  • And since Bob and Duer will likely complain and ask "why didn't you test this in the test server" I will answer that question in advance:

    I don't have 20 players to just have migrate to the test server for a day, a fully setup map with props, purchased doors, and props linked to those doors.

    This is the only way to really test it out and see what things need to be fixed and tweaked.
  • CheesyBread wrote:

    And since Bob and Duer will likely complain and ask "why didn't you test this in the test server" I will answer that question in advance:

    I don't have 20 players to just have migrate to the test server for a day, a fully setup map with props, purchased doors, and props linked to those doors.

    This is the only way to really test it out and see what things need to be fixed and tweaked.
    Hey it's not just us. A ton of people asked for the post to be made and people agreed 17 to 3. We also already have a test server with a fully setup map, props made, purchased doors and linked doors and one could easily transfer the live server database to the test server. I know of a lot of people willing to test too. But whatever takes the minimum amount of effort is how its going to be done. There were 4 admins helping test when you first added the old plugin. We had found numerous prop bugs, data loss bugs, cop bugs all in the span of an hour and I'm very glad we were there to catch all those things before it went live.

    Now ignoring that for a second since I already gave up on this server I just like to help the friends I've made and no longer wish to debate the actions especially where I fixed the out of entity error on the old plugin without all this fancy prop code.

    Anyways are you able to come up with anything to make it easier to link props to doors? I think before you had to /propowner playername to any prop. Would you be willing to implement a way to tag every single prop you want to link with a door with a crowbar or other weapon? Admins *mostly the guy that got demoted* would sometimes fuck up and link props from another room accidentally or override another players props breaking the system.

    If at all possible or if someone is willing to do it. I think having a system that would let someone just type say /linkprops 455 and for the next 30 seconds and any furniture you hit with a crow bar or stunstick etc would link the prop to door 455. That way you couldn't link props from another house and actually linking props to a door would be extremely fast compared to running the command individually on all props and risk targeting things not intended. I believe m_hLastAttacker is still tracked even if furniture isn't destroyable but I'm not 100% positive.

    The post was edited 13 times, last by BobVeka ().

  • I made some fixes to the furniture plugin. I added some additional logging to the furniture plugin for better debugging, and fixed a few bugs with it. I also made some changes to the core code for improved tracking of object types.

    Unfortunately the cause of the crashing is still unknown. The memory leak is fixed, and we aren't having any issues from edict overflows. It's this totally different error that has no definite fix. I've tried a wide variety of different actions on the test server and I couldn't get her to chooch over.

    Also I set the crime rate for robbing an npc to 20/second if you aren't a robber, and 10/second if you are using the Robber job.

    - Plants are fixed
    - (After next crash or map restart) Crime rates changed; Fixes applied to furni plugin; Added console logging to furni plugin for future fixes.
  • The server crashes have nothing to do with player props. If so then the error we would be getting is ED_Alloc: No Free Edicts (or something of that order).

    The error we used to be getting was with a memory leak, but the furniture plugin + fixes to the main plugin killed both errors.

    Now we have one that is vague, and has almost no information on it online called "Snag Mismatch". It has nothing to do with furniture.
  • syle22 wrote:

    SV_PackEntity: SnagChangeFrameList mismatched number of props[103 vs 99]

    L 10/02/2016 - 03:41:25: Engine error: SV_PackEntity: SnagChangeFrameList mismatched number of props[103 vs 99]

    literally wtf
    Yeah that's the one that was left after I fixed all crashes on the old plugin before the new plugin went in place. Unless someone removed it my entity logger will show that it always crashes on either player death or player spawn. It's possibly the weapon removal system or crashing when money is dropped. Those are the only two conditions I can think of that would cause that ent generation and a mismatch. That was the only error the old plugin had after adjusting money and hourly trash cleanup. The entity logger also shows all ents created and deleted. So if someone wants to find the true cause they can open the log file and look for 103 or 99 of a kind or type. There is also this plugin installed that dumps the crash log and uploads it online for viewing a bit deeper When the crash didn't happen the server would have 3 days uptime. Generally when fighting was at a minimum.

    I had let other devs know about that error ages back and that I was unable to fix it and got a bunch of laughs and/or no serious attempt at it.

    ColdRP, BlueRP, TfsRP all had that error daily when the server was busy. Sometimes it would even happen every 3 hours.

    Once the new jobs and custom weapons were added after the whole new respect system and event. I had planned to try the player_weaponstrip point entity or having gold drop 1 at a time rather than all at once. No guarantees at all either things would work though.

    That's been an error going on for years now that the entire dev team is aware of.

    The post was edited 4 times, last by BobVeka ().

  • I have Accelerator installed, but it was completely useless. I have to see if I still have your crash reporting installed on the server.

    What I might need to do is add some lists, and any time the plugin wants to create an entity, add it to that list. Then maybe do an OnGameFrame thing where X entities get created per frame if the list contains any requests to create entities.

    Either that or maybe it would be possible to just have the main plugin and it's modules notify the main plugin of how many entities it wants to remove or create. Maybe something like:

    //returns true if it is safe to create more entities, false if not
    bool AreEntityChangesSafe();

    //increases the number of known entity changes occurring.
    void AddNumEntityChangeRequests(int amount);

    Then in the core plugin, I would have a variable:
    g_NumEntityChanges = 0;
    AddNumEntityChangeRequests would just do g_NumEntityChanges += amount.

    then I just do
    OnGameFrame() {
    if(g_NumEntityChanges > 0)

    The idea here would be simple: Any time any RP code wants to create or destroy entities, have it first call AreEntityChangesSafe(). If that function returns true, then continue with creating or destroying ents. If not, then handle that somehow such as by using a timer to do the entity work later. Right before doing the entity changes, the plugin should call AddNumEntityChangeRequests(n), where n is the number of entity changes (killing or creating) that is expected to occur. Perhaps a system such as this could prevent this crashing from happening.
  • CheesyBread wrote:

    Also it appears that plugin is not running.

    I can't seem to find it. Would you mind linking me it? I believe. It's not perfect but it logs all created and destroyed ents. It's the whole reason along with the accelerator that I originally redid the prop code. It showed admins accidentally using duplicate on things other than props via missing the prop and crashing the server. Completely accidental of course but yeah anything that could happen would happen when it came to crashes unfortunately with anything a player is able to do.

    Good luck.

    The post was edited 2 times, last by BobVeka ().