Skip to content

We shouldn't send the client block updates for chunks they don't have #144

@crazy2be

Description

@crazy2be

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)
}

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions