From fc0e7b1d72df809ae52eb0b53ca99c2c31043b80 Mon Sep 17 00:00:00 2001
From: James Lyne <jim+github@not-null.co.uk>
Date: Wed, 12 Jan 2022 01:19:29 +0000
Subject: [PATCH] Updated Configuring Multiple Servers (markdown)

---
 Configuring-Multiple-Servers.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Configuring-Multiple-Servers.md b/Configuring-Multiple-Servers.md
index e441ad8..ec07f15 100644
--- a/Configuring-Multiple-Servers.md
+++ b/Configuring-Multiple-Servers.md
@@ -12,13 +12,13 @@ This subdirectory-based approach was chosen for its relative simplicity and beca
 ## Requirements
 - **LiveAtlas on an external webserver**
   
-  Multiple server support **requires** LiveAtlas be hosted on an external webserver. The internal Dynmap/Pl3xmap webservers will not work for this as they do will not route the server URLs correctly.
+  Multiple server support **requires** LiveAtlas be hosted on an external webserver. The internal Dynmap/Squaremap/Pl3xmap webservers will not work for this as they do will not route the server URLs correctly.
 
 - **All configured servers accessible externally via a browser**
 
-  LiveAtlas needs to be able to make requests to each configured server from the visitor's browser. This means all of your configured dynmap/Pl3xmap server URLs need to be publicly accessible, and meet all browser imposed restrictions:
+  LiveAtlas needs to be able to make requests to each configured server from the visitor's browser. This means all of your configured Dynmap/Squaremap/Pl3xmap server URLs need to be publicly accessible, and meet all browser imposed restrictions:
 
-  - If your servers are accessed via a [different origin](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#definition_of_an_origin) to LiveAtlas itself, then you will need to ensure [CORS headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) are configured correctly. Headers for the Dynmap internal webserver can be configured using dynmap's [http-response-headers setting](https://github.com/webbukkit/dynmap/wiki/Configuration.txt#http-response-headers)
+  - If your servers are accessed via a [different origin](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#definition_of_an_origin) to LiveAtlas itself, then you will need to ensure [CORS headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) are configured correctly. Headers for the Dynmap internal webserver can be configured using Dynmap's [http-response-headers setting](https://github.com/webbukkit/dynmap/wiki/Configuration.txt#http-response-headers)
 
     Alternatively, you can configure your webserver as a reverse proxy and make all individual servers accessible from the same origin LiveAtlas is hosted on, which will avoid this issue.
 
@@ -52,7 +52,7 @@ This subdirectory-based approach was chosen for its relative simplicity and beca
 
     Multiple server support is configured in index.html. Look for the `<script>` containing the `window.liveAtlasConfig` object and edit the `servers` property to include the servers you want to be accessible within LiveAtlas. The key of each server object will be used in the URL to access it. 
 
-    Each server object should contain a `dynmap` or `pl3xmap` property which contains the URLs necessary for displaying the map. Dynmap maps require several URLs which can be found in the `standalone/config.js` file for the server. Pl3xmap maps require just the URL the map is currently viewable at. Making all URLs absolute is recommended to avoid ambiguity.
+    Each server object should contain a `dynmap`, `squaremap` or `pl3xmap` property which contains the URLs necessary for displaying the map. Dynmap maps require several URLs which can be found in the `standalone/config.js` file for the server. Squaremap and Pl3xmap maps require just the URL the map is currently viewable at. Making all URLs absolute is recommended to avoid ambiguity.
 
     An example with 2 dynmap servers named `creative` and `survival` and a 3rd Pl3xmap server: