Frequently Asked Questions

General

What does this mod do?

The SKO Nanobot Build and Repair System automatically welds, repairs, grinds, and collects floating objects within its range. It replaces tedious manual work with an automated system that can be configured per block through the terminal and tuned server-wide through a configuration file.

Does this mod replace the original mod or do I need both?

This mod fully replaces the original. It uses the same block type, so you can simply remove the original mod from your world and add this one — your existing Build and Repair blocks will continue to work in the same saved world.

What is the difference between the two versions of this mod?

Nanobot Build and Repair System (Maintained) - Nerfed Version — A rebalanced version where the block requires more resources and is heavier to build.

Nanobot Build and Repair System (Maintained) - Original Resources Version — Identical in functionality and fixes, but uses the same build components as the original mod. Only the required build resources differ between the two.

Can I use multiple versions of this mod at the same time?

No. Running multiple versions of the mod in the same world will not work and may break things. Use only one version at a time.

Does it work in Creative mode?

Yes. In Creative mode the system will weld and build blocks without requiring components to be present in inventory, matching the behaviour of the original mod.

Does it work with the Shields mod?

Yes. The mod includes built-in checks for the Shields mod. When a target is protected by a shield, the system will skip it. This check is enabled by default and can be disabled in ModSettings.xml if needed.

Does it work with DLC blocks?

Yes. As of v2.5.4, the Build and Repair system no longer performs its own DLC entitlement check — the projector already enforces DLC at projection time, so any block that has been projected is by definition allowed to be built. Removing the redundant check also fixes an offline-mode issue where projected DLC blocks were skipped because the offline DLC table was empty (BUG-104).

Does it work with the multigrid projection plugin?

Yes, welding of projected grids using the multigrid-projection plugin is supported.

Known limitation: In some cases the multigrid-projection plugin can break welding. The plugin patches native game API calls, which may not always work as expected. If you encounter a block that cannot be welded, try welding it manually with your hand welder or a standard ship welder first. If manual welding also fails, the issue is caused by the plugin — not by the Build and Repair system. Please report such cases to the multigrid-projection plugin team.

What blocks can the system pull components from and push items to?

The system scans for source inventories (to pull components for welding) and push targets (to offload items after grinding or when the inventory is full). Both use the same set of supported block types. The block must be connected to the Build and Repair block via the conveyor network.

Supported block types:

Cargo Containers
Connectors
Conveyor Sorters
Assemblers
Refineries
Ship Grinders
Ship Welders (excluding other Build and Repair blocks, to prevent circular transfers)
Cryo Chambers

Blocks on connected grids (via connectors, pistons, rotors) are also included as long as they are reachable through the conveyor system. The system rescans for sources and push targets every 30 seconds.

Installation & Troubleshooting

The mod does not seem to work. How do I troubleshoot or reinstall it?

Follow these steps in order:

Exit the game completely.
In Steam, open the game's Properties → Betas and make sure None is selected to ensure you are running the latest game version.
Go to the mod page on Steam, click Unsubscribe, and wait 5–10 seconds for Steam to remove the files.
Click Subscribe again and wait 5–10 seconds for the download to complete.
Start the game.
In your mod list, place this mod towards the end of the list so it loads after other mods.
If progression is enabled in your world, the Build and Repair block must be researched before it appears. It is located near the Welder in the progression tree. If progression is disabled, search for "Build and" in the block list.
If you are using a custom ModSettings.xml, make sure it is not an outdated version. See the Configuration File page for the current format.
If Steam still does not download the mod correctly, try manually deleting the mod's folder from your Steam workshop content directory, then reload the session to trigger a fresh download.
If you are using server-side or client-side plugins such as Multi-Grid-Projector, try disabling them to see if the problem goes away. Some plugins patch game API calls in ways that can interfere with mod behaviour. If you identify a plugin conflict, please open an issue so it can be investigated.

I cannot find the Build and Repair block in the build menu.

Type /nanobars -help in chat. If a help window appears with the mod version, the mod is loaded. If nothing happens, the mod is not active in your world or server.
The block appears under the Large Blocks, Small Blocks, and Tools categories.
If progression is enabled, you need to research the block first. It is located near the Welder in the progression tree.

Progression tree showing the Build and Repair block near the Welder

The mod shows an initialisation error in the control panel info panel.

This usually means the mod was not fully downloaded on the server — a known issue with Steam on dedicated servers where mods are sometimes only partially downloaded. The server then starts with an incomplete mod, which causes errors.

Stop the server, delete the mod's cached folder from the workshop content directory, and restart to force a clean download.

The mod is not working correctly after an update.

In some cases issues can be caused by an outdated configuration file (ModSettings.xml) that contains settings from an older version. To rule this out:

Make a backup of your current ModSettings.xml.
Delete the original file and restart the server or session.
Generate a fresh configuration file using /nanobars config create.
Compare the new file with your backup and merge any custom settings you need back into the new file.

This ensures you are using a configuration file that matches the current version of the mod.

Block Seems Stuck

The Build and Repair block is not doing anything. What should I check?

Work through this checklist:

Is the block powered and enabled?
Is Auto Pull/Push enabled? Without it, the system cannot pull the components it needs to weld.
Check the work mode — try switching between modes to see if that helps.
Is the inventory full, or are required components missing?
Are you inside a Safe Zone that does not have Weld, Grind, or Build enabled?
Do you have Shields active on the target? Shields prevent grinding.
Are you using a server plugin that protects grids, such as the !protect command from ALE PCU Transferrer? Protected grids cannot be welded or ground.
Check the block's Search Mode dropdown — Walk mode (default) only sees grids connected to the BaR via connectors, pistons, rotors, or mergers, while Fly mode also picks up unconnected grids inside the work area. The wrong choice for your situation can hide the target from the BaR. See Welding → Search Mode for the full breakdown.
Check the info panel in the terminal — it often shows a specific reason why the system is idle.
Are you using a block or PCU limiter plugin on the server (e.g. BuildLimiter for Torch)? These plugins can silently prevent blocks from being placed or welded without any visible error message. Ask your server admin whether any build limits are in effect.
If you are an admin on a listen-server or single-player session, try the in-world cluster overlay: /nanobars debug cluster-area. It draws every cluster's per-member working area in 3D space, so you can see at a glance whether the cluster's reach actually covers the target grid. Combine with /nanobars debug targets to see which blocks are discovered and which are already assigned to a system. See Debug & Diagnostics → Cluster-Area Overlay.

Could a build limiter plugin be blocking my blocks?

Yes. Some dedicated servers run plugins that enforce block count, PCU, or block-type limits — for example BuildLimiter (a Torch plugin). When a limit is reached, the plugin silently prevents new blocks from being placed or welded. The Build and Repair system sees the block as a valid target and tries to weld it, but the plugin intercepts the operation and nothing happens. There is no error message — the block simply appears stuck.

How to check:

Ask your server admin if a build limiter or PCU limiter plugin is installed and whether you have hit a limit.
Try manually welding the same block with your hand torch. If manual welding also does nothing, a plugin is likely blocking the operation.
Check if only certain block types are affected — limiter plugins often restrict specific types (e.g. turrets, refineries) rather than all blocks.

This is not a bug in the Build and Repair system. The mod cannot detect or bypass server plugin restrictions. Contact your server admin to adjust the limits or free up capacity.

Performance

I have many Build and Repair blocks and my server sim speed is dropping. What can I do?

Version 2.5.0 includes major performance improvements for servers running many systems. If you are on an older version, update first.

If sim speed is still low after updating, try these steps:

Place Build and Repair blocks close together so they form a cluster. Clustered blocks share scanning work automatically, dramatically reducing CPU usage.
Lower MaxBackgroundTasks in ModSettings.xml (default: 4). This limits how many background scans run in parallel.
Increase EmptyGridRescanDelaySeconds (default: 20). Grids with no targets are skipped for this many seconds.
Reduce MaxSystemsPerTargetGrid to limit how many systems pile onto one grid.
The mod automatically throttles when sim speed drops below 1.0 — let it recover before adding more blocks.

What is the Cluster Scan Coordinator?

When multiple Build and Repair blocks share the same working area, they automatically elect a single coordinator to scan for targets. The coordinator scans once and shares the results with all members. This eliminates redundant scanning and can reduce scan CPU usage by roughly 80% with 10 co-located blocks. If the coordinator is disabled or removed, a new one is elected automatically. You do not need to configure anything — it works out of the box.

For the full mechanics (cluster keys, election, what causes BaRs to land in different clusters), see Other Features → Cluster Coordinator.

Weld Modes

What are the different weld modes?

The terminal dropdown offers three weld modes:

Weld to full (default) — Welds every block to 100% integrity.
Weld to functional — Welds blocks just enough to become functional (lights on, doors work, thrusters fire). Saves components and time when you don't need full armour integrity.
Skeleton only — Only places projected blocks (the first component). Does not weld or repair existing blocks. Great for quickly laying out an entire blueprint from a projector, then switching to Full or Functional to finish the job.

How do I quickly build a large ship from a projection?

Set up your projector with the blueprint.
Set all your Build and Repair blocks to Skeleton only mode.
Make sure Build new is enabled in the terminal.
The blocks will rapidly place all projected blocks (one component each).
Once all blocks are placed, switch to Weld to full or Weld to functional to weld them up.

This two-step approach is much faster than welding each block to completion before placing the next one.

I switched from the old "Weld to functional only" checkbox. Where did it go?

It has been replaced with the Weld mode dropdown in the terminal. If your block previously had "Weld to functional only" checked, it will automatically appear as Weld to functional in the new dropdown. No action is needed — your saved settings are preserved.

Where did the "Allow Build" option go?

It was renamed to Build Projections in the terminal. The behaviour is identical — when on, the BaR welds projected blocks; when off, only existing damaged blocks. The label was changed because "Allow Build" was easy to misread as a master on/off for the whole system, while "Build Projections" makes the actual scope obvious.

Existing per-block settings carry over automatically. Server admins still configure it via AllowBuildDefault / AllowBuildFixed in ModSettings.xml (those XML names did not change), and Programmable Block scripts still use BuildAndRepair.AllowBuild. See Welding → Build Projections.

Scanning & Detection

Why does it take a few seconds before my Build and Repair blocks start welding a new projection?

When you first activate a projector, the Build and Repair blocks do not immediately know about the projected blocks — the cluster coordinator needs to scan and discover them first.

As of v2.5.4, projector cold-start detection is fast: when a projection becomes buildable, the BaR picks it up within roughly 1–2 seconds. (Previously, an empty grid could be skipped for up to 20 seconds by the idle-grid backoff before being rescanned.) Once the first few blocks have been welded and new scans complete, the rest of the projection is processed at full speed.

A fresh projection still ramps up gradually: only one block is buildable on the first scan, more blocks become buildable as their neighbours are completed, and the BaR's pace visibly accelerates as the projection grows. See Welding → Projector Cold-Start for the full breakdown.

My BaR is not welding the wreck (or unconnected ship) sitting next to it. Why?

The BaR's Search Mode defaults to Walk, which only sees grids that are part of the same logical group as the BaR — i.e. connected via connectors, pistons, rotors, or mergers. Anything sitting in space near the BaR but not actually attached to it is invisible in Walk mode.

Switch the BaR's Search Mode dropdown to Fly to also scan unconnected grids inside the work area — wrecks, salvage, projector pads, ships parked nearby without a connector lock, etc. Fly mode applies to both welding and grinding. See Welding → Search Mode and Grinding → Search Mode.

Welding & Grinding Issues

The block is grinding my own grid. What is wrong?

Two common causes:

You have set a grind color that matches your build color. The system interprets all blocks with that color as grind targets. Check and update the grind color setting in the terminal.
Some blocks on your grid may have been transferred to an enemy or neutral owner, making them valid grind targets. Check block ownership.

The block will not weld a specific target block. Why?

Try welding the same block manually with your hand torch. If that also fails, something is physically in the way or a required DLC is missing.
Check that you own the DLC required to build the target block.
Check for obstructions — a wheel or misaligned component is a common culprit. Remove the obstruction, let the system weld the rest, then weld the blocked component manually or via the system afterwards.
If you are using a plugin such as Multi-Grid-Projector, try disabling it and testing again. Plugins that patch game API calls can affect welding behaviour in unexpected ways.

Two BaRs are next to the same block but only one is welding it. Why?

This is the block assignment system working as intended. As soon as one BaR picks a block to weld it claims a short reservation (default 8 seconds), and other BaRs in range treat the reserved block as taken and look for a different target. The result is that several BaRs near the same area spread out across the available targets instead of all bunching up on one block.

If you specifically want every BaR to focus on the same target — for example to weld a single critical block as fast as possible — disable the system server-wide with AssignToSystemEnabled = false in ModSettings.xml. To loosen reservations more aggressively when BaRs come and go (without disabling the system entirely), lower AssignmentTtlSeconds. See Welding → Block Assignment for the full picture, including the related MaxSystemsPerTargetGrid per-grid cap.

Debug Mode & Diagnostics

What is Debug Mode and how do I use it?

Debug Mode is a server-wide setting that surfaces extra diagnostic information (scan timings, active target counts, cluster membership, internal state flags) in every BaR's terminal custom info panel. It is intended for testing only — leave it off in production.

For the full description, including how to turn it on / off, the in-world debug HUD overlay, the built-in profiler, the BuildId, and how to report issues, see the Debug & Diagnostics page.

How do I run the built-in profiler?

The profiler is an admin-only tool accessed through chat commands. /nanobars profile start [seconds] starts a session (auto-stops after the given seconds, default 120); /nanobars profile stop ends it and writes the logs.

For the full command list, log file locations, and tips on what to share when reporting performance issues, see Debug & Diagnostics → Built-in Profiler.

Configuration (Server Admins)

Can I change settings like range, sounds, and particle effects?

Yes. Many options can be configured through the ModSettings.xml file. See the Configuration File page for the full list of available options.

How do I create the server configuration file?

Run /nanobars config create in-game (admin only). This saves the current settings to ModSettings.xml in the mod's storage folder.

On a dedicated server, you can also change settings at runtime using /nanobars config set <setting> <value> and then save them with /nanobars config save. Most settings take effect immediately, but some changes (such as range, power, and welder-specific settings) require a session restart to apply.

Can I change settings without restarting the server?

Yes. As of v2.5.0, most settings can be changed at runtime using chat commands (admin only):

/nanobars config list — see all settings and their current values
/nanobars config set MaxGrindsPerTick 8 — change a setting immediately
/nanobars config save — save changes to ModSettings.xml so they persist after restart
/nanobars config reload — reload settings from ModSettings.xml
/nanobars config reset — reset all settings to defaults

Most settings take effect immediately. However, some changes (such as range, power, and welder-specific settings) require a session restart to apply.

How do I disable the ticking sound for all players?

Set DisableTickingSound to true in ModSettings.xml. This silences the ticking/unable sound globally for all blocks and all players on the server.

How do I disable the flying nanobot particle effects for all players?

Set DisableParticleEffects to true in ModSettings.xml. This disables the flying nanobot trace animations globally. Players can also toggle this per block in the terminal, unless the global setting is already forcing it off.

How do I limit how many systems can work on the same grid at once?

Use the following settings in ModSettings.xml:

MaxSystemsPerTargetGrid — the maximum number of systems allowed to work on the same target grid simultaneously. Defaults to 20 in local and listen-server games and 10 on dedicated servers. Setting this in the config file overrides whichever default applies.
DisableLimitSystemsPerTargetGrid — set to true to remove the limit entirely.

This prevents many systems piling onto a single grid while others nearby are ignored.

How do I disable reputation loss when grinding enemy or neutral grids?

Set DecreaseFactionReputationOnGrinding to false in ModSettings.xml. By default, grinding grids belonging to other factions or NPCs causes a reputation penalty, matching manual grinding behaviour.

Safe Zones

Does the system respect Safe Zones?

Yes. The system checks Safe Zone rules before welding, grinding, or building projections:

Grinding enemies inside a Safe Zone you or your faction do not own is blocked.
Grinding inside your own Safe Zone is allowed when the relevant Safe Zone option is enabled in the Safe Zone settings panel.

These checks can be disabled in ModSettings.xml if needed.

My grid is partially inside a Safe Zone and some blocks are not working. Why?

When a grid straddles a Safe Zone boundary, Build and Repair blocks inside the zone have different permissions than those outside. The system automatically creates separate work groups for blocks inside and outside the Safe Zone, so each group has a coordinator that matches its permissions.

If all your blocks are inside a Safe Zone that blocks welding or grinding, they will be idle — this is correct behaviour. Move blocks outside the zone or adjust the Safe Zone settings to allow the operations you need.

The system is welding or grinding a protected grid. How do I stop it?

If you are using the ALE PCU Transferrer plugin for Torch, use the !protect command on the grid. The system will detect the protection flags and skip it entirely. Use !unprotect to make the grid accessible again.

Terminal & Priorities

How do the Weld and Grind priority lists work?

The priority lists control which block types the system targets first. Each block class (e.g. Armor, Thrusters, Reactors) can be enabled or disabled and reordered using the Up and Down buttons in the terminal. The system processes enabled classes from top to bottom.

Use the Enable All and Disable All buttons to quickly toggle every entry at once.

What does "Ignore Priority Order" do?

This toggle exists for grinding only. When enabled, the BaR ignores the order of the grind priority list and simply targets the nearest available grind block, regardless of its block class. The enabled/disabled state of each class is still respected — only the ordering is bypassed. There is no equivalent for welding or collecting; those always follow the priority list when picking the next target.

How do I reset a block back to its default settings?

Open the block's terminal and click Reset All Settings. This restores all settings for that block to their defaults, including the priority list states.

Companion Script

Where can I find the companion auto-queuing script?

Important: the companion script only works with SKO's maintained versions of the mod. It will not work with the original mod by Dummy08.

A maintained version of the script is available on the Steam Workshop: Nanobot Build and Repair System Queuing / Display / Scripting (Maintained)

The script source is also included in this repository under SKO-Nanobot-BuildAndRepair-System-Script/.

See the Companion Script documentation for setup and configuration details.

What does the companion script do and how do I set it up?

The companion script runs on a Programmable Block and handles automatic assembler queuing and multi-display status output for one or more Build and Repair System groups. It can show current weld/grind targets, missing components, and transport status on LCD panels or cockpit screens.

Setup:

Place a Programmable Block on your grid.
Open the script from the Steam Workshop link above and paste it into the Programmable Block editor.
Edit the BuildAndRepairSystemQueuingGroups array at the top of the script to match your block and assembler names or group names.
Compile and run the script. It updates automatically on every 100-tick cycle.

Community & Support

Where can I get help or ask questions?

Join the Discord server and ask in the #help-topics channel: https://discord.gg/5XkQW5tdQM

You can also open an issue on GitHub if you believe you have found a bug: https://github.com/SKO85/SE-Mods/issues

Can I donate to support development?

Yes, donations are very welcome and appreciated: Donate via PayPal