Redstone Simulator Rewrite

[tigerw]

Doesn't matter, redstone wire updates right now (seems to have fixed itself...)

[tigerw]

Is there a reason why std::deque causes a crash when you give it a struct with more than three items?

[xoft]

A struct? Wat?

[tigerw]

Like;

struct derpy
{
    BLOCKTYPE derpblock
    Vector3i derpcoords
    NIBBLETYPE derpmeta
}

typedef std::deque <derpy> derpylist

derpylist m_derpyblocklist

Having more than three in the struct would cause MCS to inexplicably crash. But I recompiled and it fixed itself.

(wat)

[FakeTruth]

It sometimes happens that an incremental build becomes corrupt, you can spend hours debugging and not finding the problem. It depends on how complex the project is how often this happens so it shouldn't happen much with MCServer though. I've had the problem more often when compiling with gcc than with visual studio.

[xoft]

Oh, btw, deque is not a good container for this; neither is a list. Really, you want to use a vector. Otherwise the thing will be slow as hell.

[tigerw]

I'm very confused with deques/vectors. My current issue is that still I get 'vector not incrementable' if I use SetBlock (which pushes blocks to be ticked into a deque), but not so with FastSetBlock (which doesn't do any updates).

A general view of the problem is like this:

cRedstoneSimulator::WakeUp
{
    ...
    case E_BLOCK_REDSTONE_TORCH
        m_Blocks.push_back(x, y, z)
    ...
}
cRedstoneSimulator::Simulate
{
    for (BlockList::iterator itr = m_Blocks.begin(); itr != m_Blocks.end(); ++itr) // BlockList is a std::vector <Vector3i>
    {
        BLOCKTYPE Block = m_World.GetBlock(*itr)
        ...
        case E_BLOCK_REDSTONE_TORCH
            HandleRedstoneTorch(*itr)
        ...
    }
}
cRedstoneSimulator::HandleRedstoneTorch(Vector3i a_BlockPos)
{
    ... (Powered torch?)
    // This tells me that vectors are not incrementable
    m_World.SetBlock(a_BlockPos, E_BLOCK_REDSTONE_TORCH_OFF, 0)
    // This works fine
    m_World.FastSetBlock(a_BlockPos, E_BLOCK_REDSTONE_TORCH_OFF, 0)
    ...
}

I have no idea why, and pistons are broken because the QueueSetBlock. The only time I delete entries is with:

m_Blocks.clear()

...at the end.

Is it because I can't have two (processes?) accessing a deque at the same time, and will therefore need a lock?

---

Yay, a

cCriticalSection m_Cs;

did it. Are critical sections good? I have no idea what they are.

[FakeTruth]

You mean this is a runtime exception and not a compile error right?

This might mean you are having some threading problems and things are not threadsafe. Or you are modifying m_Blocks inside HandleRedstoneTorch

[tigerw]

You mean this is a runtime exception and not a compile error right?

This might mean you are having some threading problems and things are not threadsafe. Or you are modifying m_Blocks inside HandleRedstoneTorch

I see, anyway, a cCriticalSection seems to have fixed it.

---

Actually, false alarm.

I will look at threading issues, somehow.

[tigerw]

Hurrah! Redstone updates without exception (hopefully!)!

I'll prove to xoft that I haven't "...chickened out..." yet!