Nanobot Build and Repair System Queuing / Display / Scripting

Full automatic queuing of missing materials and displaying block status on panel(s)

This is a simple out of the box script, to be used with the Nanobot Build and Repair System Block. For details see Nanobot Build and Repair System. !! This script is designed to work with this block only !!

Using this script will enable full automatic queuing of missing materials into the configured assemblers. Optional you could also configure the script to show status information about the BaR-Systems at one or multiple text panels.

How it works

Put the script into a programmable block. To configure the scipt itself you have two options:

[olist] [*] Putting all build and repair systems (that should be able to queue) into a group named "BuildAndRepairGroup1", and put all assemblers that should use for queuing into a second group called "AssemblerGroup1", if you like to display some status information on a panel, just place a text panel and name it "BuildAndRepairGroup1StatusPanel" and that's it.

[*] For more complex scenarios, where you have two or more groups of build and repair systems that work independently, you have the option to define as many groups as you need.

At the top of the script you will find a static array called: BuildAndRepairSystemQueuingGroups, where you can put your groups in. Every group is an entry of the type BuildAndRepairSystemQueuingGroup Every group has four properties:

• BuildAndRepairSystemGroupName: The name of a group containing Build and Repair Systems
• BuildAndRepairSystemNames: A list of names of individual Build and Repair Systems
• AssemblerGroupName: The name of a group containing assemblers
• AssemblerNames: A list of names of individual assemblers
• DisplayNames: A list of names of text panels where the system info should be displayed (Empty if no panels should be used)
• DisplayKinds:A list that defines the information that should be alternating displayed. You could choose out of these informations ( DisplayKind.Status, DisplayKind.ShortStatus, DisplayKind.MissingItems, DisplayKind.WeldTargets, DisplayKind.GrindTargets, DisplayKind.CollectTargets )
• DisplayMaxLines: Defines the items that should be displayed in case of listings 'Missing items', 'WeldTargets', ..
• DisplaySwitchTime: Time in seconds after that the next information page is displayed. (If "DisplayKinds" has only on element this value is ignored)

You could use every combination of the four properties to discribe your logical group. So for e.g. if you define a "BuildAndRepairSystemGroupName" and a list of "BuildAndRepairSystemNames" names. In the end the script will internally manage a combined list of every system in the group plus the individual given systems. The same applies for the assembler properties.

So lets make an example:

You have 2 logical groups of repair systems. Lets say one works in the hangar bay1 and the other in hangar bay2. So you define four groups "Hangar1BaRSystems"/"Hangar1Assemblers" and "Hangar2BaRSystems"/"Hangar2Assemblers". In that case your configuration will look like:

static BuildAndRepairSystemQueuingGroup[] BuildAndRepairSystemQueuingGroups = {
   new BuildAndRepairSystemQueuingGroup() {
      BuildAndRepairSystemGroupName = "Hangar1BaRSystems",
      AssemblerGroupName = "Hangar1Assemblers"
   },
   new BuildAndRepairSystemQueuingGroup() {
      BuildAndRepairSystemGroupName = "Hangar2BaRSystems",
      AssemblerGroupName = "Hangar2Assemblers"
   }
};

If you decide to put individual system names into the script it could look like:

static BuildAndRepairSystemQueuingGroup[] BuildAndRepairSystemQueuingGroups = {
   new BuildAndRepairSystemQueuingGroup() {
      BuildAndRepairSystemNames = new[] { "Hangar1BaRSystem1", "Hangar1BaRSystem2" },
      AssemblerNames = new[] { "Hangar1Assembler1", "Hangar1Assembler2" }
   },
   new BuildAndRepairSystemQueuingGroup() {
      BuildAndRepairSystemNames = new[] { "Hangar2BaRSystem1", "Hangar2BaRSystem2" },
      AssemblerNames = new[] { "Hangar2Assembler1", "Hangar2Assembler2" }
   }
};

As sayed before you could mix both methodes as you like:

static BuildAndRepairSystemQueuingGroup[] BuildAndRepairSystemQueuingGroups = {
   new BuildAndRepairSystemQueuingGroup() {
      BuildAndRepairSystemGroupName = "Hangar1BaRSystems",
      AssemblerGroupName = "Hangar1Assemblers"
      AssemblerNames = new[] { "Hangar1AssemblerReserve1" }
   },
   new BuildAndRepairSystemQueuingGroup() {
      BuildAndRepairSystemGroupName = "Hangar2BaRSystems",
      BuildAndRepairSystemNames = new[] { "Hangar2BaRSystemOptional1" },
      AssemblerGroupName = "Hangar2Assemblers"
   }
};

[/olist]

If you define an emtpy group, or none block of the right type there will be an error message displayed in the detail section of the programmable block.

Further the script refreshes the given groups every 2 minutes, so if you put a new block inside a group, it will be detected latest after 2 minutes. If you don't whant to wait, you could go to the programmable block, open and close the editor, this will force the detection immediately.

Feel free to use this script in your own designs.

• If you like to use the block in your own scripts, the class RepairSystemHandler encapsulates all the functions the block offers and is designed to handle one or a list of systems to be used parallel. (In order to use the class you need also the base classes EntityHandler and EntityHandler<T>)

Have fun.