From 23e2bc504245b28835ff7958798b3a715f783c31 Mon Sep 17 00:00:00 2001
From: Alexander Harkness <me@bearbin.net>
Date: Mon, 21 Dec 2015 18:07:13 +0000
Subject: Added analytics to APIDump

---
 Server/Plugins/APIDump/UsingChunkStays.html | 43 ++++++++++++++++++++---------
 1 file changed, 30 insertions(+), 13 deletions(-)

(limited to 'Server/Plugins/APIDump/UsingChunkStays.html')

diff --git a/Server/Plugins/APIDump/UsingChunkStays.html b/Server/Plugins/APIDump/UsingChunkStays.html
index a7cb5302a..faedfdfaa 100644
--- a/Server/Plugins/APIDump/UsingChunkStays.html
+++ b/Server/Plugins/APIDump/UsingChunkStays.html
@@ -14,7 +14,7 @@
 			<p>
 			A plugin may need to manipulate data in arbitrary chunks, and it needs a way to make the server
 			guarantee that the chunks are available in memory.</p>
-			
+
 			<h2>The problem</h2>
 			<p>
 			Usually when plugins want to manipulate larger areas of world data, they need to make sure that the
@@ -27,7 +27,7 @@
 			either the block area has incomplete data (Read() failed) or incomplete data has been written to the
 			world (Write() failed). Recovery from this is near impossible - you can't simply read or write again
 			later, because the world may have changed in the meantime.</p>
-			
+
 			<h2>The solution</h2>
 			<p>
 			The naive solution would be to monitor chunk loads and unloads, and postpone the operations until all
@@ -47,7 +47,7 @@
 			despawned. So the callback must use the longer way to access such objects, such as calling
 			<a href="cWorld.html">cWorld:DoWithEntityByID()</a> or
 			<a href="cWorld.html">cWorld:DoWithPlayer()</a>.</p>
-			
+
 			<h2>The example</h2>
 			<p>
 			As a simple example, consider a theoretical plugin that allows a player to save the immediate
@@ -66,13 +66,13 @@ function HandleCommandSaveSpawn(a_Split, a_Player)
 	local SpawnZ = a_Player:GetWorld():GetSpawnZ()
 	local Bounds = cCuboid(SpawnX - 25, SpawnY - 25, SpawnZ - 25, SpawnX + 25, SpawnY + 25, SpawnZ + 25)
 	Bounds:ClampY(0, 255)
-	
+
 	-- Read the area around spawn into a cBlockArea, save to file:
 	local Area = cBlockArea()
 	local FileName = a_Player:GetName() .. "_spawn.schematic"
 	Area:Read(a_Player:GetWorld(), Bounds, cBlockArea.baTypes + cBlockArea.baMetas)
 	Area:SaveToSchematicFile(FileName)
-	
+
 	-- Notify the player:
 	a_Player:SendMessage(cCompositeChat("The spawn has been saved", mtInfo))
 	return true
@@ -96,7 +96,7 @@ function HandleCommandSaveSpawn(a_Split, a_Player)
 	local SpawnZ = a_Player:GetWorld():GetSpawnZ()
 	local Bounds = cCuboid(SpawnX - 25, SpawnY - 25, SpawnZ - 25, SpawnX + 25, SpawnY + 25, SpawnZ + 25)
 	Bounds:ClampY(0, 255)
-	
+
 	-- Get a list of chunks that we need loaded:
 	local MinChunkX = math.floor((SpawnX - 25) / 16)
 	local MaxChunkX = math.ceil ((SpawnX + 25) / 16)
@@ -108,11 +108,11 @@ function HandleCommandSaveSpawn(a_Split, a_Player)
 			table.insert(Chunks, {x, z})
 		end
 	end  -- for x
-	
+
 	-- Store the player's name and world to use in the callback, because the a_Player object may no longer be valid:
 	local PlayerName = a_Player:GetName()
 	local World = a_Player:GetWorld()
-	
+
 	-- This is the callback that is executed once all the chunks are loaded:
 	local OnAllChunksAvailable = function()
 		-- Read the area around spawn into a cBlockArea, save to file:
@@ -124,7 +124,7 @@ function HandleCommandSaveSpawn(a_Split, a_Player)
 		else
 			Msg = cCompositeChat("Cannot save the spawn", mtFailure)
 		end
-		
+
 		-- Notify the player:
 		-- Note that we cannot use a_Player here, because it may no longer be valid (if the player disconnected before the command completes)
 		World:DoWithPlayer(PlayerName,
@@ -133,14 +133,14 @@ function HandleCommandSaveSpawn(a_Split, a_Player)
 			end
 		)
 	end
-	
+
 	-- Ask the server to load our chunks and notify us once it's done:
 	World:ChunkStay(Chunks, nil, OnAllChunksAvailable)
-	
+
 	-- Note that code here may get executed before the callback is called!
 	-- The ChunkStay says "once you have the chunks", not "wait until you have the chunks"
 	-- So you can't notify the player here, because the saving needn't have occurred yet.
-	
+
 	return true
 end
 </pre>
@@ -150,7 +150,7 @@ end
 			when we've got the chunks loaded, there's still the issue of free RAM - if the memory for the area
 			cannot be allocated, it cannot be read even with all the chunks present. So we still do need that
 			check.</p>
-			
+
 			<h2>The conclusion</h2>
 			<p>
 			Although it makes the code a little bit longer and is a bit more difficult to grasp at first, the
@@ -163,5 +163,22 @@ end
 				prettyPrint();
 			</script>
 		</div>
+
+		<!-- Piwik -->
+		<script type="text/javascript">
+		  var _paq = _paq || [];
+		  _paq.push(['trackPageView']);
+		  _paq.push(['enableLinkTracking']);
+		  (function() {
+			var u="https://analytics.cuberite.org/";
+			_paq.push(['setTrackerUrl', u+'piwik.php']);
+			_paq.push(['setSiteId', 5]);
+			var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
+			g.type='text/javascript'; g.async=true; g.defer=true; g.src='piwik.js'; s.parentNode.insertBefore(g,s);
+		  })();
+		</script>
+		<noscript><p><img src="https://analytics.cuberite.org/piwik.php?idsite=5" style="border:0;" alt="" /></p></noscript>
+		<!-- End Piwik Code -->
+
 	</body>
 </html>
-- 
cgit v1.2.3