#world editor crash investigation

1 messages · Page 1 of 1 (latest)

lusty ferry
#

Hey, I just checked it and there is a problem related to Door_Village_E_B_LEFT_INT which might be a named entity in your world?

#

Best to search in the world editor for that string and lets see together what shows up.

#

If you have a reliable reproduction of your world crashing every time it would also probably help us investigate if you send it to us as a zip. We already have your mod list through the report you sent 🙂

#

You might also try and crash again and send another report, as the first one did not fully process on our end

royal dock
#

Seems I'm hitting a replication limit?

I've made it so doors are stored in replication as we are trying to keep track using the Persistence addon for a lock system we are building, seems to work fine until we try Eden as there is a ton more doors.

This is the entity script we use, we were overriding the Door_Base entity to apply to all doors in the map

class SOP_DoorEntityClass: GenericEntityClass {}

class SOP_DoorEntity: GenericEntity {
    
    [RplProp()]
    protected RplId _itemId;
    
    //------------------------------------------------------------------------------------------------
    override void EOnInit(IEntity owner)
    {
        UpdateRplId(owner);
    }
    
    //------------------------------------------------------------------------------------------------
    void UpdateRplId(IEntity item)
    {
        Rpc(RpcAsk_UpdateRplId, Replication.FindId(item));
    }
    
    //------------------------------------------------------------------------------------------------
    [RplRpc(RplChannel.Reliable, RplRcver.Server)]
    void RpcAsk_UpdateRplId(RplId itemId)
    {
        _itemId = itemId;
        Replication.BumpMe();
    }
    
    //------------------------------------------------------------------------------------------------
     RplId GetRplId()
    {
        return _itemId;
    }
    
}

Not sure how else I can get the doors to register in replication so I can get it to work, that is a work around for making an entity insert itself into replication as by default they don't even with Self Insert on

lusty ferry
#

Oh hey okay that would explain it. Please do not add repliction components to doors or replicated properties. There are just way too many doors in the world. this is why for my modded persistence framework i introduced an extra handler to keep track of non default state doors so a map of like 10k of them only stores the relevant 300 or what ever.
Anything that there is a lot of in the world like houses, doors, trees and rocks especially please be very careful of if and what you add

#

Let me know what exactly you are trying to achieve and I can provide you with a less resource intensive setup idea 🙂

royal dock
#

I have a prefab the player is required to have that allows them to "attach" aka use the item to gain the ability to lock/unlock doors

#

I am assuming if I go the route you had setup with door states once a certain % of doors are modified as in "owned" it would cause the same issue due to the number of entities?

lusty ferry
#

Yes and no, the way I set things up even if all of them are non default state is not a huge problem. a) Everything is only allocated on the server in terms of info so people with little ram do not need to worry about all the components on all doors eating up like 300mb just for existing in default state. And b) If you tweak the network communication a little bit so not every player gets all the info about all the doors in the world there would not be much traffic cost to syncing this kind of "ownership". Though in general I would usually suggest owning a full building instead of all individual doors , that already cuts down your data by like 1/5th given that many buildings have so many doors

#

As for tracking ownership and syncing it. tracking i would do via the moddable door state struct, there is info on hot to interact with it on my github documentation on the mod.
And syncing could be done by the server sending nearby door info to players via rpc when they get close to a relevant one. like your own little network bubble implementation.

royal dock
lusty ferry
#

Not even a component here, I would just put a manager entity into the world that can handle keeping track of all buildings/doors when they change to non default on the server and sends info selectively to players so their door user actions can display the info. you can just deny opening on the server side handling but then players might not understand why the action did nothing so a text of "door is locked" might help

#

Oh also you just need to send the door ownership info to players who get near a door they own i just realize

#

just tell everyone else by default that they can not open it if there is some lock entity on it

royal dock
#

Yea I have that already in the logic, overriding the default SCR_DoorUserAction and checks if the door is locked although this was done via a component with a boolean attached, will change this obviously but should still work the same in principal

#

just shows "Locked" along with being disabled