local X = math.floor(Player:GetPosX())
local Y = math.floor(Player:GetPosY())
local Z = math.floor(Player:GetPosZ())
local Radius = Split[3]
for X = -Radius, Radius do
for Y = -Radius, Radius do
for Z = -Radius, Radius do
Execute( X, Y, Z, Player, Split, Target, World )
end
end
end
but it keeps saying that X, Y, Z are 0 and then they do the radius stuff around X=0, Y=0 and Z = 0
03-21-2013, 05:17 AM (This post was last modified: 03-21-2013, 05:18 AM by xoft.)
The point is, with a for loop, the computer knows the number of iterations, so it can optimize it in some ways.
Anyway, for a more complete example: (I hope I'll get it right, no promises though)
Code:
local PlayerX = a_Player:GetPosX();
local PlayerY = a_Player:GetPosY();
local PlayerZ = a_Player:GetPosZ();
local Area = cBlockArea();
if (not(Area:Read(a_Player:GetWorld(), PlayerX - 8, PlayerX + 8, PlayerY - 8, PlayerY + 8, PlayerZ - 8, PlayerZ + 8, cBlockArea.baTypes + cBlockArea.baMetas))) then
-- Cannot read the area around player, bail out
return;
end
local x, y, z;
for y = -8, 8 do
for z = -8, 8 do
for x = -8, 8 do
local BlockType, BlockMeta;
BlockType, BlockMeta = Area:GetRelBlockTypeMeta(x, y, z, BlockType, BlockMeta);
-- stupid ToLua makes us write the last two arguments, they are otherwise useless and unused
-- Do something with the block
end -- for x
end -- for z
end -- for y
I don't know what your Execute function does, I suppose it's doing something with block in the world using World:GetBlock(); that is gonna be really slow. You really really want to use the BlockArea version of this.
1, Cache values. You're building the key name, then forgetting it, then rebuilding it again, then forgetting, then rebuilding... Use a local variable to build it once and then use it.
2, What class exactly is Block? I'm guessing that its FindKey() and GetValue() do almost the same - both search an underlying storage for a key name and return its position or value. Can't you use just one?
On a different note, I've found that the bug in Floody has been there before, so it's not been introduced by my optimization. So I committed the faster code, now I have to track down the bug.
I fixed the server stopping on Linux, turns out it was something completely different than I originally thought.
cListenThread was counting on OS waking up from a select() call when one of the sockets was closed. Apparently, this isn't the case on Linux, so I put in additional wakeups by timeout every 1 second (semi-busywait).
omg TortoiseSVN is frustrating. i want to commit my changes to the core but it wants to commit it to http://mc-server.googlecode.com/svn/trunk/ without my allowing to change it >.<
the only problem is that it is realy realy slow. becouse for each block it does this:
)
