Random Chitchat 2012-2016

[cedeel]

I have no idea where to implement this. Do I need to make a separate simulator just for setting metadata?

Here is my code: https://dl.dropbox.com/u/21041937/leaves.patch
Let me know if I you found any mistakes in the code. I'm still learning how to program.

A separate simulator would probably be the best way to go, since you are "simulating" leaf decay.

[xoft]

The problem with leaves is that they need to check a relatively large area of blocks, possibly across up to 4 chunks. Using cChunk::UnboundedRelGetBlock() can get slow in such a case, we might need to do a "get area of blocks" first.

---

I don't think a separate simulator is necessary, this is more about block-ticking than simulating physics. A separate block-tick function would do (same as TickGrass, for example)

[cedeel]

I'm trying to get authentication to work.

Current status: Works with a dirty hack.

However, it's really slow (some part of cBlockingTCPLink causing it as far as I can tell)

When I say slow, I mean 1 minute of waiting...

[xoft]

Let me know if I you found any mistakes in the code. I'm still learning how to program.

Your code that was checking the 9x9x9 neighbors for a log was flawed - if the block was less than 4 blocks away from a chunk's edge, it would have checked a wrong block, even could've caused a crash. cChunk::GetBlock() function only works for blocks inside the chunk, your code needs to check outside the chunk as well, so it needs to use cChunk::UnboundedRelGetBlock().

Onde more thing: The wiki says "and connected to the log by other leaf blocks". Your code only checks if there is a log block, but doesn't check for the actual connection.

As for the changes in neighboring blocks causing the leaves to be checked for decay again, that needs to be done in the cChunk::CheckBlocks(), it maintains a list of block adjacent to recently changed blocks, and checks them.

[xoft]

I just got fed up with the cWorld::GetBlockEntity() deprecation warning, I'm gonna rewrite it into a safe and easy set of calls exported to Lua.

[xoft]

Problems, problems everywhere.
To test the new ForEach functions I tried implementing a KillPickups command that would destroy all pickups within a chunk. But there's a problem:
- The only place where Lua can get a valid cEntity pointer is inside the callback function
- It isn't safe to call cEntity::Destroy() inside the callback function, because it breaks the entity enumeration
So how do I destroy entities in Lua?
I guess there's one more function I need to do - cWorld::QueueDestroyEntity(), accessible from Lua. And remove cEntity:Destroy() from Lua interface, since it's useless there. Oh man, it's getting difficult.

[FakeTruth]

Huh? What??

The Destroy() function is actually there for (safely) queuing the deallocation of objects, there should be no need for another queue

[xoft]

Remember that the callback is called while the entities are being enumerated in a for-loop? that for-loop fails because the iterator is no longer valid after Destroy() has been called (Destroy() removes entities from the chunk, invalidating any iterators)

[FakeTruth]

Ah right... I think the Destroy() function needs to be changed then? It should always be safe to call the Destroy() function.

Another *fix* would be grabbing the next iterator before using the previous. That way, if the previous iterator was to be removed, you still have a valid next iterator. This fix feels like a hack though, and if for some reason the next iterator was to be removed, it would fail.

[xoft]

Another *fix* would be grabbing the next iterator before using the previous. That way, if the previous iterator was to be removed, you still have a valid next iterator. This fix feels like a hack though, and if for some reason the next iterator was to be removed, it would fail.

Actually that is the best thought on this. There is no way anyone should "grab" another iterator while this one is being used other than calling the ForEach() API inside the callback function, we can simply say this is unsupported.

There's no hack-ish about this solution - you're giving an iterator away and someone could trash it, so why not store the info you need out of it for later?