This is pretty minor, since the client will just ignore them, but it's a waste of bandwidth and it's triggering annoying warnings in the JavaScript console.
To reproduce: Have two clients. With one client, dig really far down. Open the JavaScript console on the other client, and continue digging with the original client. Observe the warnings about ignored block messages.
I think the logic is wrong somewhere here:
// Applies the given block change to the currently queued chunks
// Returns true if the change was applied (the block has not yet been
// sent), false if it should be sent to the client instead (they already
// have the chunk).
// This is needed to avoid sending stale chunks to the client.
func (cm *ChunkManager) ApplyBlockChange(bc coords.Block, b mapgen.Block) bool {
cm.mutex.Lock()
defer cm.mutex.Unlock()
cc := bc.Chunk()
status, exists := cm.chunks[cc]
if !exists {
// We don't techincally apply the block change to ourselves if the
// chunk does not exist in our list, but we don't want it to be sent
// to the client, so we return false regardless.
return false
}
if status.sent {
return false
}
if status.data == nil {
log.Println("WARN: Recieved block change for chunk that is not loaded (this probably shouldn't happen?)")
return false
}
oc := bc.Offset()
status.data.SetBlock(oc, b)
return true
}
Or maybe where it's called:
if !c.cm.ApplyBlockChange(m.Pos, m.Type) {
conn.Send(m)
}
This is pretty minor, since the client will just ignore them, but it's a waste of bandwidth and it's triggering annoying warnings in the JavaScript console.
To reproduce: Have two clients. With one client, dig really far down. Open the JavaScript console on the other client, and continue digging with the original client. Observe the warnings about ignored block messages.
I think the logic is wrong somewhere here:
Or maybe where it's called: