ApexRMS · spearmangillman · Apr 1, 2026 · Apr 2, 2026 · Apr 9, 2026 · Apr 9, 2026
diff --git a/docs/_scenarios/section2.md b/docs/_scenarios/section2.md
@@ -121,10 +121,10 @@ Here are some short descriptions of each stage:
         * Required inputs: Template Raster File, Field Data, Covariate Data. 
         * Outputs: Updated Field Data and Site Data.
 
-4. <u>Background Data Generation</u>: 
-    * Generates background sites (pseudoabsences), extracts covariate data for the pseudoabsence sites and updates the Field Data and Site Data to include pseudoabsence data. 
-        * Required inputs: Template Raster File, Field Data, Covariate Data, Site Data. 
-        * Outputs: Updated Field Data and updated Site Data. 
+4. <u>Background Data Generation</u>:
+    * Generates background sites (pseudoabsences), extracts covariate data for the pseudoabsence sites and updates the Field Data and Site Data to include pseudoabsence data.
+        * Required inputs: Template Raster File, Field Data, Covariate Data, Site Data.
+        * Outputs: Updated Field Data and updated Site Data.
 
 5. <u>Prepare Training/Testing Data</u>: 
     * Divides Field Data into training and testing sets and/or cross validation folds based on the provided Validation Options arguments. 

diff --git a/docs/_scenarios/section3.md b/docs/_scenarios/section3.md
@@ -151,6 +151,8 @@ The **Field Data Options** *Datasheet* can be found under the **Field Data** tab
 
 The **Background Data Options** *Datasheet* controls some of the *Scenario's* settings relating to the **Field Data**.
 
+> If the *Background Data Generation* stage is re-run (e.g., when running a dependent scenario or re-running an existing scenario), any existing background sites already present in the **Field Data** will be removed and regenerated based on the current **Background Data Options**. To preserve existing background data instead of regenerating it, set *Generate background sites* to "No".
+
 ### **Generate background sites**
 Defines whether background sites should be generated for the *Scenario*. Background sites are also referred to as pseudo-absences and represent absences of a species. This information allows the models to compare environmental spaces where a species can and cannot be found. Background sites are often used when true absence data are not available for a species.
 

diff --git a/docs/_scenarios/section6.md b/docs/_scenarios/section6.md
@@ -115,6 +115,8 @@ The **Probability Map** is the main output of the fitted model and shows probabi
 ### **MESS Map**
 The **MESS Map** is the Multivariate Environmental Similarity Surface, which represents values as positive, negative, or zero. This map shows how well locations on the **Template Raster** fit into the range of covariate data to which the training data were fit. Positive areas on this map represent areas where the covariate ranges are more similar to those to which the training data of the model were fit. Negative areas on this map represent areas where the covariate ranges are not similar to those to which the training data of the model were fit. Values of zero on this map represent areas where ranges of covariate data at these locations and ranges of covariate data to which the training data of the model were fit are marginally similar [(Elith et al., 2010)](https://doi.org/10.1111/j.2041-210X.2010.00036.x).
 
+> MESS and MoD maps are computed on continuous variables only. If the model includes categorical variables, those variables are excluded from the calculation and a warning is issued. If all model variables are categorical, MESS and MoD maps cannot be generated and will be skipped.
+
 ### **MoD Map**
 The **MoD Map** is a map of the most dissimilar variable. This map is similar to the **MESS Map** in that it shows regions where covariate ranges were most dissimilar from those used to fit the training data. However, this map shows which covariates used in the model was furthest from the range of the observations used for model training and where.
 

diff --git a/docs/index.md b/docs/index.md
@@ -15,13 +15,13 @@ permalink: /
 
 ### WISDM is an open-source <a href="https://syncrosim.com/" target="_blank">SyncroSim</a> package for developing and visualizing species distribution models. <br>
 
-WISDM was designed to update and replace <a href="https://doi.org/10.1111/j.1600-0587.2012.07815.x" target="_blank">VisTrails SAHM</a>, a software application originally developed in 2013 by the U.S. Geological Survey (Morisette et al. 2013). The WISDM package streamlines your <a href="https://en.wikipedia.org/wiki/Species_distribution_modelling" target="_blank">species distribution modeling</a> (SDM) workflows by preparing data, fitting model ensembles, and visualizing model outputs. WISDM maintains records of the various data inputs, processing steps, and modeling options used during SDM construction, and allows users to customize and run existing SDM methods, such as <a href="https://en.wikipedia.org/wiki/Generalized_linear_model" target="_blank">Generalized Linear Models</a>, <a href="https://en.wikipedia.org/wiki/Random_forest">Random Forest</a>, and <a href="https://biodiversityinformatics.amnh.org/open_source/maxent/" target="_blank">Maxent</a>, without having to interact with different software platforms. WISDM also allows users to easily visualize and compare model scenarios from within the SyncroSim user interface.
+WISDM was designed to update and replace <a href="https://doi.org/10.1111/j.1600-0587.2012.07815.x" target="_blank">VisTrails SAHM</a>, a software application originally developed in 2013 by the U.S. Geological Survey (Morisette et al. 2013). The WISDM package streamlines your <a href="https://en.wikipedia.org/wiki/Species_distribution_modelling" target="_blank">species distribution modeling</a> (SDM) workflows by preparing data, fitting model ensembles, and visualizing model outputs. WISDM maintains records of the various data inputs, processing steps, and modeling options used during SDM construction, and allows users to customize and run existing SDM methods, such as <a href="https://en.wikipedia.org/wiki/Gradient_boosting" target="_blank">Boosted Regression Trees</a>, <a href="https://en.wikipedia.org/wiki/Generalized_additive_model" target="_blank">Generalized Additive Models</a>, <a href="https://en.wikipedia.org/wiki/Generalized_linear_model" target="_blank">Generalized Linear Models</a>, <a href="https://biodiversityinformatics.amnh.org/open_source/maxent/" target="_blank">Maxent</a>, and <a href="https://en.wikipedia.org/wiki/Random_forest">Random Forest</a>, without having to interact with different software platforms. WISDM also allows users to easily visualize and compare model scenarios from within the SyncroSim user interface.
 
 <br>
 
 ## Requirements
 
-This package requires SyncroSim <a href="https://syncrosim.com/download/" target="_blank">version 2.5.5</a> or higher. <br>
+This package requires SyncroSim <a href="https://syncrosim.com/download/" target="_blank">version 3.1.27</a> or higher. <br>
 <a href="https://www.java.com" target="_blank">Java</a> is also required if you choose to run Maxent models within the WISDM package.
 
 <!--- > Instructions for installing the above requirements for WISDM are provided on the [Getting Started](https://apexrms.github.io/wisdm/getting_started.html) page. -->

diff --git a/src/00-constants.R b/src/00-constants.R
@@ -3,6 +3,11 @@
 ## ApexRMS, October 2025
 ## -------------------------
 
+# Use Cairo backend for PNG rendering on Linux to avoid X11 display dependency
+if (.Platform$OS.type == "unix" && capabilities("cairo")) {
+  options(bitmapType = "cairo")
+}
+
 # Raster nodata sentinel value — must match nodataValue in setup_functions.py
 nodataValue <- -9999
 

diff --git a/src/00-helper-functions.R b/src/00-helper-functions.R
@@ -555,7 +555,7 @@ safe_rbind <- function(df, row) {
 
 # Launch a Shiny app with browser detection ------------------------------------
 
-launchShinyApp <- function(appPath) {
+launchShinyApp <- function(appPath, appName = "Viewer") {
   # Search PATH first — works on all platforms (Linux, macOS, Windows)
   chrome.names <- c(
     "google-chrome",
@@ -617,8 +617,32 @@ launchShinyApp <- function(appPath) {
     }
   }
 
-  # Final fallback: let Shiny use the OS default (xdg-open / open / shell.exec)
-  if (is.null(browser.path)) {
+  # On headless Unix (Docker or bare Linux server with no DISPLAY), bind to
+  # 0.0.0.0:3838 so the app is reachable via port forwarding from the host.
+  # A browser is still launched if one is found (e.g. via X11 forwarding).
+  # Chrome/Firefox require --no-sandbox when running as root.
+  # On non-headless Unix or Windows, behaviour is unchanged.
+  headless_unix <- .Platform$OS.type == "unix" &&
+    nchar(Sys.getenv("DISPLAY")) == 0
+
+  if (headless_unix) {
+    port <- 3838
+    progressBar(
+      type = "message",
+      message = paste0(
+        "ACTION REQUIRED: Open http://localhost:",
+        port,
+        " in your browser to use the Interactive ",
+        appName
+      )
+    )
+    shiny::runApp(
+      appDir = appPath,
+      host = "0.0.0.0",
+      port = port,
+      launch.browser = FALSE
+    )
+  } else if (is.null(browser.path)) {
     shiny::runApp(appDir = appPath, launch.browser = TRUE)
   } else {
     shiny::runApp(appDir = appPath, launch.browser = function(shinyurl) {

diff --git a/src/04-background-data-functions.R b/src/04-background-data-functions.R
@@ -26,7 +26,8 @@ backgroundSurfaceGeneration <- function(sp,         # species
 
     if ('kde' %in% method) { 
       if(tolower(method$surface) == "continuous"){
-        kde_bg_out <- gsub('/', '\\\\', paste0(outputDir, '/', sp, '_kde_bg_surface.tif'))
+        kde_bg_out <- paste0(outputDir, '/', sp, '_kde_bg_surface.tif')
+        if (.Platform$OS.type == "windows") kde_bg_out <- gsub('/', '\\\\', kde_bg_out)
         kde.mat <- matrix(m, nrow = length(unique(ud@coords[, 1])))
 
         t <- terra::rast(raster::raster(ud))