Pipes disppear when linked to quarry

Hi,

ive noticed that pipes connected to a quarry disappear on a server restart, is it possible to look into this bug?

Can I check which version you are using. There was an issue with pipes to quarries being lost on server restart but I thought that had been fixed.

I'm also seeing this. I'm running v0.9.20, and it only started recently. The pipe will stay in place and work as expected until the server restarts. Then all pipes are there except the one going to the quarry. I reconnect it and it all starts working again. 

It is happening at all quarries. I'll get the plugin version changed out. Is the additional logging just to the console?

It produces log files.

Ok. We can pull the logs after my daily reboot and see what happens. So long as the pipe disappears again, I'm hoping there's something useful in the logs.

Thanks

I'm guessing that it's the logs in oxide/logs/SyncPipes/

You'll find the contents below.

finderrors:

[Error]: ------------------- 871892 -------------------
[Error]: Entity not found
[Error]: Type: General
[Error]: 

runtime:

[Error]: Object reference not set to an instance of an object
[Error]: Exception thrown in DataStore1_0.Converter.ReadJson
[Error]: plugins_84526796
[Error]:   at Oxide.Plugins.SyncPipes+PipeEndContainer..ctor (BaseEntity container, Oxide.Plugins.SyncPipes+ContainerType containerType, Oxide.Plugins.SyncPipes+Pipe pipe) [0x00096] in <c875a6bf05214931a849c9344651d0f7>:0 
  at Oxide.Plugins.SyncPipes+Pipe..ctor (Newtonsoft.Json.JsonReader reader, Newtonsoft.Json.JsonSerializer serializer) [0x00460] in <c875a6bf05214931a849c9344651d0f7>:0 
  at Oxide.Plugins.SyncPipes+Pipe+Converter.ReadJson (Newtonsoft.Json.JsonReader reader, System.Type objectType, System.Object existingValue, Newtonsoft.Json.JsonSerializer serializer) [0x00000] in <c875a6bf05214931a849c9344651d0f7>:0 
  at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.DeserializeConvertable (Newtonsoft.Json.JsonConverter converter, Newtonsoft.Json.JsonReader reader, System.Type objectType, System.Object existingValue) [0x00055] in <2ae3f091decd4989b3c4d466e6eb5985>:0 
  at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize (Newtonsoft.Json.JsonReader reader, System.Type objectType, System.Boolean checkAdditionalContent) [0x000d9] in <2ae3f091decd4989b3c4d466e6eb5985>:0 
  at Newtonsoft.Json.Serialization.JsonSerializerProxy.DeserializeInternal (Newtonsoft.Json.JsonReader reader, System.Type objectType) [0x00008] in <2ae3f091decd4989b3c4d466e6eb5985>:0 
  at Newtonsoft.Json.JsonSerializer.Deserialize (Newtonsoft.Json.JsonReader reader, System.Type objectType) [0x00000] in <2ae3f091decd4989b3c4d466e6eb5985>:0 
  at Newtonsoft.Json.JsonSerializer.Deserialize[T] (Newtonsoft.Json.JsonReader reader) [0x00000] in <2ae3f091decd4989b3c4d466e6eb5985>:0 
  at Oxide.Plugins.SyncPipes+DataStore1_0+Converter.ReadJson (Newtonsoft.Json.JsonReader reader, System.Type objectType, System.Object existingValue, Newtonsoft.Json.JsonSerializer serializer) [0x00061] in <c875a6bf05214931a849c9344651d0f7>:0 

Thanks for the logs. I'll try and dig into it some more.

I did notice that with the new plugin, it actually deleted all the pipes that were at the monument (the other thread I posted in). I updated line 2422 to the line below to let me readd them. I don't know if it'll stay after the reboot, but I'll post logs if they look different.

if (!ContainerHelper.InMonument(entity) && !playerHelper.IsAdmin)​


Merged post

No new logs after the latest restart, and the pipes stay in place. This is still running with the beta version and my modification listed above.

I did some tests using Sync Pipes v0.9.20 and noticed that after the server restart the containerid of the quarry.
Created a simple scenario Quarry --> large box --> large box and compared the data file.

first:

"containers": [
    {"ci":106579,"cs":true,"dn":null},
    {"ci":108469,"cs":true,"dn":null},
    {"ci":110510,"cs":true,"dn":null}
  ]

After restart there is one container gone - pipe from the quarry is gone, containers list in the data file looks like this:

"containers": [
    {"ci":106579,"cs":true,"dn":null},
    {"ci":108469,"cs":true,"dn":null}
  ]


Then reconnected the quarry and then it looks like:

"containers": [
    {"ci":106579,"cs":true,"dn":null},
    {"ci":108469,"cs":true,"dn":null},
    {"ci":131992,"cs":true,"dn":null}
  ]


Is this container id generated by the plugin or is it oxide that manages that?
 

It looks like you have something there.
The containers should always get the same id. The challenge with the quarries is the 2 storage containers are generated at each restart so it has to work off the quarry id and then find the containers again each time the server restarts and it looks like the id has changed.

Are you using a specific plugin to manage quarries on your server?

No I am testing this on a vanilla server with only the syncpipes plugin loaded.

Did some more troubleshooting, and the net.ID of the quarry & pumpjacks seem to change after every restart, while previously they were consistent.
To test this I slightly changed the OnHammerHit method to do some troubleshooting by letting it just output the entity id

void OnHammerHit(BasePlayer player, HitInfo hit)
        {
            
            if (player == null || hit?.HitEntity == null)
                return;
            var entity = hit.HitEntity;
            SendReply(player, GetMsg("Entity ID: " + entity.net.ID, player));
        }

I'm not too familiar with rust plugins but I suppose there is no other identifier on an entity than the net id that can be used to identify an entity?

 

Are you hitting the quarry or one of its containers?

On my server the quarry retains the same id after each restart (but the containers change)

Merged post

My test code is a little bit cruder lol

        void OnHammerHit(BasePlayer player, HitInfo hit)
        {
            Puts($"{hit.HitEntity.ShortPrefabName} ({hit.HitEntity.net.ID})");
        }​

[Debug] mining_quarry (4591)
[Debug] fuelstorage (4661)
[Debug] hopperoutput (4659)

Restarted Server:

[Debug] mining_quarry (4591)
[Debug] fuelstorage (5665)
[Debug] hopperoutput (5663)

This was stored by SyncPipes as 4591 (which allows it to reconnect after restart).