BARABAS (universal base and ship script)

BARABAS

(Burillo's Automatic Resource Administration for BAses and Ships)

TL;DR

Will manage your refineries and prioritize ore, will transfer cargo from ships to base or other ships, has various notifications, has very few naming conventions, will work on base or ships of practically any size. The only mandatory requirement is a programming block. Geared towards vanilla ore mechanics, don't use with ore/ingot/refinery mods (well, you can try, but don't be surprised if it doesn't work). Link to code at the end of the post. If there is an unstable version that is later than stable version, please also try that before reporting issues. Also, check known limitations.

Side effects when running BARABAS:

• Most blocks will have conveyor functionality disabled.

Mods are supported on a best-effort basis


Description

Is BARABAS for you? Maybe, maybe not. The more specialized your use case is, the more likely BARABAS will not work for you. BARABAS isn't meant for advanced players who come up with complex contraptions and like to micromanage their base; its use case is the opposite of that - BARABAS does all the micromanagement so you don't have to. So if you can't be arsed to constantly watch your ore/ingot levels and refueling your reactors every now and then, and would like to concentrate on mining and building instead - BARABAS is for you.


Capabilities

• Enforced grid locality
• Automatic intelligent ore management (including dynamic prioritization)
• Refinery and assembler declogging
• Tracking oxygen/hydrogen levels and oxygen leaks detection
• Stop refining ice whenever oxygen/hydrogen reaches certain levels
• Auto refuel oxygen/hydrogen on connection (disabled by default)
  
• Automatically scales to include/exclude whatever you build or lose
• Tracks uranium and battery levels
• Detects damaged blocks
• Detects disconnected blocks
  
• Displays storage load percentage and total cargo mass
• Throwing out stone and gravel while keeping configurable amounts of gravel
• Color-coded alerts, textual status report and HUD notifications
  
• Auto transfer everything from/to connected ships
• Storage containers sorting
• Different modes of operation, detection of common specialized ships (grinder, welder, drill)
• Supports ship-to-base connections in all modes, also ship-to-ship connections in "tug" mode
• Ships refuel themselves with Uranium when connected to base
• Crisis mode for when storage is running low when in "base" mode
• Exclude blocks whose custom name starts with "X" from being affected by BARABAS
• On-the-fly reconfiguration using configuration stored in programming block's Custom Data

Usage

To use BARABAS on your ship/base, simply put a programming block and paste the code (or subscribe to the workshop item). The programming block will rename itself to "BARABAS Base CPU" or "BARABAS Ship CPU", depending on the configuration.

It is important to note that BARABAS is very conservative when it comes to things like where to put ore or ingots. With the exception of Stone (which can go to the connector to be thrown out), ore will be either in storage or in a refinery. A connector is not considered to be storage. Also, BARABAS is very careful not to push too much of the same ore into refineries and will always leave free space for other ore. To put it in other words, in an effort to avoid clogging, BARABAS "wastes" a lot of cargo space, so make sure you have enough!

Configuration

In most cases, BARABAS's defaults will work fine, but if you want to tweak BARABAS's operation, you can edit its configuration. All configuration values are adjusted automatically if "auto" mode is used.

Limitations

The main limitation (by design) is that you *must* have everything on a single conveyor network. Multiple conveyor networks and disconnected processing units are explicitly not supported, and will never be.

When running BARABAS, it is always the ship that initiates all transactions. So, no base-to-base transactions will happen, and ship-to-ship transactions can only happen when one of the ships is in "tug" mode.

Yet another limitation is what BARABAS considers "a ship" and "a base". From BARABAS's point of view, any grid that has a thruster or a wheel on it is a ship. While grid detection is very reliable (any weird configuration will work), ships that do not have any thrusters/wheels will be detected as bases by other ships, which will cause problems. This does not apply if all ships are running BARABAS - the two ships will correctly detect each other's grid type.

BARABAS also generally expects storage containers to be present. While BARABAS will work without storage containers, it will only balance refineries and provide you with alerts - it will not transfer anything to or from ships.

BARABAS also is not aware of filter blocks and refinery upgrades, so it will not make any adjustments to accomodate for those. BARABAS is not a micro-manager's script, so if you are one and want to control every aspect of every refinery - BARABAS is not for you. (alternatively, you can exclude certain blocks from being managed by BARABAS)

Finally, BARABAS was built by a person who rarely engages in combat and doesn't really use weapons that much. Hence there is no support for weapons and ammo.


Mandatory requirements

• Storage containers must be present (it'll work without it, but most of the functionality will be useless)
  
• Everything must be on a single conveyor network

Optional requirements

• There has to be a group of connectors named "BARABAS Trash", designated for waste disposal (otherwise an arbitrary connector will be used instead)
• Sensors can also be made part of "BARABAS Trash" group, used to stop trash throw out.
  
• Group of lights, text/LCD panels and beacons/antennas named "BARABAS Notify", used for notification and status reports.

Code

NOTE: Unstable version from Github may be newer than unstable version on Workshop, but the Workshop version is guaranteed to have less WIP stuff and thus less weird bugs and unfinished behavior.
NOTE 2: the source code no longer fits into the 100000 character limit, so it has to be minified. You can use various online minification services or tools in IDE's, but just in case, i wrote a simple code minifier. Just run the executable, copy the code, press "Minify clipboard", and paste it into the programming block.

Link to latest stable code (v1.7): https://raw.githubusercontent.com/burillo-se/BARABAS/v1.7/BARABAS.cs
BARABAS on GitHub: https://github.com/burillo-se/BARABAS
BARABAS releases: https://github.com/burillo-se/BARABAS/releases

Link to stable code on Steam Workshop: https://steamcommunity.com/sharedfiles/filedetails/?id=399873500
Link to unstable code on Steam Workshop: https://steamcommunity.com/sharedfiles/filedetails/?id=399874439

I hereby grant everyone my explicit permission to share or use my code, in parts or in whole, for whatever purposes. Attribution is encouraged, but not required. Any similarities to other scripts are not intentional and purely coincidental - there aren't a lot of ways to write the same thing...


Known issues

• Some functions rely on parsing Detailed Info of blocks, and therefore will not work when using different languages. Sadly, i have to work around the shortcomings of the API - you should nag KeenSWH about it, not me.

Changelog

1.7:

• Reworked power code, taking into account transient sources of power such as wind and solar
• Added "critical power" crisis mode, which turns off all refineries and assemblers until power situation improves
• Stone is no longer thrown out automatically - only gravel is
• Reworked ore prioritization and rebalancing code, to account for stone producing more than just gravel
• Uranium shortage is no longer indicated unless you have nuclear reactors
• Readjusted material shortage thresholds to account for changes in balancing
• Added threshold multiplier to config, to adjust further adjust material thresholds
• Fixed a few small bugs

1.65c:

• Fixed compatibility with latest PB API
• Added experimental feature to take assembler queues into account when calculating ore shortage
• [hotfix 1.65b] Fixed bug in antenna scans
• [hotfix 1.65b] Fixed text panels to set their content type automatically on adding them to BARABAS Notify group
• [hotfix 1.65c] Fixed crash on using survival kit to refine stone

1.63:

• Fix welder code that was broken since a few versions ago

1.62:

• Fixed issues with refresh rate

1.61:

• Compile fixes due to recent API changes

1.60:

• "Green mode" added
  • Limit instructions and refresh rate
• Timer is now optional
• Dropped all backwards compatibility with previous versions

1.55:

• Hotfix 2 for v1.53: fixed crash on grid discovery

1.54:

• Hotfix for v1.53: fixed a bug where oxygen leaks were constantly reported

1.53:

• Updated to latest PB API
• Deprecated config block
• Deprecated old-style trash connector and sensor
• Dropped config-file compatibility with very old BARABAS versions

1.52:

• Fixed wheel detection
• Preserve crisis state across world saves

1.51:

• Block exclusion was broken in 1.5, now it works again
• Fixed numerous potential crashes
• New feature: automatic oxygen/hydrogen refuel (disabled by default)

1.5:

• Limit the number of refineries/furnaces active at any moment to 40 randomly chosen ones
• Support for multiple trash connectors/ejectors/sensors (as part of "BARABAS Trash" group)
• Power watermarks are now a single config option instead of two options
• Added hydrogen and oxygen watermarks (anything below low watermark will sound an alarm, everything above high watermark will stop ice from refining)
• Gravel is now thrown out along with stone
• Improved grid detection algorithm, much more reliable and fixes all of the previous limitations
• Version now displayed in config block
• Exceptions are now more visible
• Disconnected blocks are now more visible
• Numerous optimizations, improvements and bug fixes

1.41:

• Maintenance update, script now works with latest SE version

1.4:

• Numerous under-the-hood optimizations, bug fixes and improvements
• New scaling state machine
• Support for HUD notifications for various blocks (oxygen leaks, damage, clogging, etc.)
  
• Support for antennas being part of the "BARABAS Notify" group
• Support for wheels
• Support for batteries
• Changed "uranium" config options to "power", now supports taking stored battery power into account
• Power left is now calculated using current power consumption
• Support for hydrogen
• Configurable oxygen/hydrogen level alerts
• Now reporting cargo mass as well as storage load
• Moved config to private text
• Merging multiple grids running BARABAS is no longer a problem
• Blue alert is redefined to mean "low power" instead of "low uranium"
• Magenta alert is redefined to also mean clogged assemblers
• Cyan alert is redefined to mean "gas shortage" (low oxygen/hydrogen)

1.31:

• Fixed compile errors with latest versions
• Fixed potential null reference errors when removing blocks

1.3:

• Added support for ice and oxygen tracking
• Added brown alert, indicating oxygen leak
• Added pink alert, indicating non-functional blocks
• Added detection of remote grid types according to their BARABAS mode
• Added support for scrap metal
• Grids are now recognized as local when loading the world even when connected to other entities at load time
• Replaced "throw out stone" flag with "keep stone", with more flexibility
• More precise material shortage tracking
• More precise storage load tracking for drills and grinders
• Display estimated ingot amounts when ore is present
  
• Improvements to ore balancing
• Improvements to state machine
• Text block now displays all alerts, not just highest level
• More fluid and flexible text updates
• Editing source code to configure BARABAS is no longer considered "supported"

1.21-1.26:

• Added basic support for ice
• Separate ore priorities for arc furnaces and refineries
• Fixed ore prioritization not spreading ore from refineries to arc furnaces in some cases
• Fixed drill/grinder load spreading doing unneeded work in some cases
• Fixed typo in config leading to exception
• Excessive stone is now thrown out even when not all stone has been refined into gravel
• Fixed detection of local lights on a separate grid (rotors, pistons)
• Fixed index out of bounds error when no arc furnaces or no refineries were present

1.2:

• Support for text panels providing status updates, in the same group as lights ("BARABAS Notify")
• New, more flexible state machine that should prevent going over the instruction limit on all but the largest bases, and also skips unnecessary steps
• Added thresholds for each material, which will indicate shortages
• Changed white alert to mean "out of some kind of material"
• Added opportunistic inventory sorting
• Greatly improved refinery ore prioritization code
• Trash disposal is now always on if designated trash connector is present
• Assemblers set to disassemble are now ignored by BARABAS
• Removed "chunk size" config option
• Fixed tug mode exception on 100% storage utilization
• Fixed miscellaneous issues with "throw out stone" flag
• Fixed ore prioritization on ships constantly reprioritizing ores
• Fixed numerous division by zero bugs

1.1:

• Added "tug" mode
• Added support for sensor ("BARABAS Trash Sensor") turning off trash disposal
• Replaced "ingots per reactor" with reactor watermarks ("reactor high watermark" and "reactor low watermark") - basically, putting enough uranium into reactors so that they are able to work at least specified amount of time, in minutes, before sounding an alarm (calculated using maximum possible power draw on current grid)
• Removed "pull uranium from base" and "push uranium to base" switches as they are counterproductive
• Added "auto_refuel_ship" (not configurable) to deal specifically with refueling
• Added "throw out stone" config option to disable stone disposal (for people using mods where stone is useful)
• Changed welder mode to not pull components from base by default and to not completely fill up welders
• Non-functioning (unfinished) blocks are now ignored
• Fixed multiple storage containers support (was broken due to to this issue)
• Fixed bug with remote grid detection where multiple ships with multiple storage containers connected to base were detected as multiple bases
• Fixed inventory consolidation sometimes reordering items
• Fixed inventory consolidation interfering with manual inventory operations
• Fixed base moving stone back and forth between storage and trash disposal in certain situations
• Better handling of trash disposal in general
• Added floating point rounding to prevent most >0.01 leftovers from ore

1.02:

• Initial release

Ideas for future versions (subject to change)

• Extending base refineries with ships' refineries

 

I'll test the script in a little bit, but I'd like to request another ship 'type': 'Tug'.

I have a base; it should work pretty much like you describe.

I have miners; they should work pretty much like you describe.

But, when the miners are full, I don't want to take the time to move them from some remote system back to the base. For this I use a 'tug'; a large ship with basically just cargo containers and a connector or two.

This is the ship I unload my miners onto; then the miners can immediately get back to mining. When the tug gets full (or sooner if I need the type of ore it contains), I drive the tug back to the base and unload. Then I take the tug back to the mining system.

So I need the miner to push ore to the tug (or the tug to pull); so, with your system I could set the tug as a 'base'.
But then I need the tug to push ore the to base (or the base to pull from the tug); with the tug a base this wouldn't work. I don't want the tug to get any ingots or components.

--Wico

 

Seems to be working on base as advertised.

I had to come back to this post to find the name of the text block.

Suggestions:

Add your 'requirements' section from above into the code block at the top. Also add the 'color coding' section.

Also, the 'start something with X to have it be ignored' is important and should be in the code comments.

--Wico

 

i'll see what i can do, but i'm not sure i can do anything about it without overcomplicating a lot of things.

the reason things are done the way they are is because while determing what you are is easy, determining what you're connected to is much harder. One of the use cases i am concentrating on is having multiple ships connected to one base. with a change you're requesting, it becomes much harder to differentiate between a complex base/ship and a "tug" ship. i could, of course, add ability to get everything from any remote storage, but that would lead to an awkward situation where a connected tug would get everything from every storage from every base and ship once connected.

if SE treated each ship as one grid regardless of merge blocks, pistons and connectors, this change would've been piece of cake. but with things the way they are, i'm afraid that it'll break too much of what i wrote this script for.

the only thing i could think of is severely limiting the tug ship - for example, if we can only find one remote grid and if we know for a fact that it's a ship, get everything from its storage, and if we know it's a base, push everything to storage. but that's very flaky and not really in the spirit of this script.

 

i've poked around to see if i can implement tug mode, and i think it's doable if i redo the whole "remote grids" thing. right now, BARABAS doesn't know if remote grid is a ship or a base. when applied to the "tug" case, it means that tug wouldn't be able to figure out if it should pull everything from the remote grid (i.e. if it's connected to a ship), or push everything to remote grid (if it's connected to base). if i separate those out and provide additional handling for tug case, this might just work without disrupting the rest of the code.

one thing i'm not sure about is how to configure what tug can push/pull. i might have to change the terminology from "push to base" to "push to receiver" or something.

 

please test this: https://pastebin.com/4xXT1ZZQ

you can turn on "tug" mode by specifying "mode = tug" in config.

the "tug" mode works by making assumptions about what you're using the tug for. if tug has a flag "push ore to base", then the tug will pull the ore from your ships and push it to base. pull flags work similarly - the tug will push stuff to ships and pull from base.

let me know if this works for you!

 

Text is too long.... 101916/100000

Sigh.

I deleted comments at the top and got it under the limit. Testing now....


EDIT: "Caught Exception: Having multiple bases is not supported." This is the only copy of the script running on the base. I deleted the text config block from prev version and it still gets exception.

Exception went away when I disconnected my tug from base connector. NOTE: the tug has a welding ship attached via another connector

base-><-tug-><-welder/grinder

Only the base had a PB with the code on it.


--Wico

 

Actually, I want it the other way around. I want the tug to PULL from miners (ships), and PUSH to base (or maybe the base does the pulling?).

--Wico

 

I setup a testing world and pasted in creative mode my elements and a base from a survival run.

I have a

• fixed station made in survival mode
• new Contrustor MkIIIC that I added BARABAS to. (with both grinders and welders... BARABAS seems to assume one or the other; I really just need Welders mode, I think)
• one of my 'tugs'. This is 3 large containers and antenna and two connectors; and a couple of arc furnaces to help reduce iron ore at the remote location and during transit.
• a couple of my auto miners. (I had to modify these; see below)

Here is the workshop link:

https://steamcommunity.com/sharedfiles/filedetails/?id=397538665

I ran my small auto miners. I added BARABAS to my tug. When I tried to unload a miner, nothing was pulled by the tug. (see my note above).

When I added BARABAS to the miner, then ore was 'pushed' to the tug. I had to modify my workshop miner to add more timer blocks; these are the ones saved in this world.

BARABAS in drill mode turns off conveyors.. and doesn't move ore out of the drills and into cargo containers. This means the miners are losing ore and my automation can't work fully because the cargo doesn't fill. I would expect BARABAS to move the ore from the drills and into the containers.. Or just not shut off conveyors on drills... I wasn't didn't notice BARABAS doing any stone removals; and there was (is) stone in the drills.


--Wico

 

i admit i didn't think to test the new tug code on base to see if it interferes with anything there... i will test the tug code more extensively today (yesterday was a quick and dirty first attempt) and fix a number of other issues. it should be under the limit though - mine fits perfectly fine... maybe pastebin does something to the code - did you copy the formatted code instead of the raw data?

thanks for providing the world though, maybe you have some peculiar use case that i hadn't thought of. constructor MKIIIC should be detected as a generic "ship", which you may then change in the config to welder or whatever else you want. i can see that your autominer has some code on it too - i don't think BARABAS should be installed on your miner at all. better to install BARABAS on the tug - it will pull all the ore from the miner without interfering with autominer's code. BARABAS doesn't do automining, it only assists in manual mining.

with regards to miner, it should pull ore from the drills to storage, and then throw out the stone through the connector. it doesn't directly move stone to connector, only through storage. if that doesn't work, try the BARABAS version from the first post - that one is well tested on multiple mining rigs, large and small. but as i said above, your miner seems to be fine on its own, no need to downgrade its functionality BARABAS isn't meant to be a be-all-end-all script, not it is intended to do automining. that said, i think your autominer is due for a makeover with textual configuration instead of beacons

when i say "pull from base" or "push to base", what i mean is, if you set a flag to push something to base, the tug will push it to base, but by enabling that you're also telling the tug to pull from ships what it has to push to base. in other words, for tug, one flag dictates two behaviours - "push ore to base" now means "push ore to base" and "pull ore from ships". and this is only for tug, other types of ships will not touch other ships at all (i.e. "push ore to base" means just that, and doesn't also mean "pull ore from ships").

in general, i guess i should've made it clearer, but all transactions with remote grids are always initiated by the ship. so as long as the ship doesn't consider itself a base, it is able to push and pull from base. however, configuring your ship as "base" doesn't mean other ships will see it as a base. your ship B may think it's a base, but it doesn't make ship A to also think that ship B is a base - from ship A's point of view, ship B is still a ship because it has thrusters. maybe when Keen adds remote code execution i'll be able to create some sort of communication mechanism between different instances of BARABAS, but for now, each instance sees its own version of reality. so, when you tell a ship to be a "base", that only means that it will see itself as a base. other ships may still think it's a ship.

so, to conclude, if you want tug to pull ore from your ships, you have to set a flag to push ore to base. but please note that tug itself will only pull stuff from ship and push stuff to base (or vice versa) - not pull from ship and push to ship at the same time. so really, a tug is still a "ship-to-base" mechanism, only with tug acting as a middle man between "ship" (drill rig) and "base" (your base) via a "ship-to-tug-to-base" kind of mechanic.

 

OK i've got good news and bad news.

good news is that i've found and fixed the bug with multiple bases, so tugging now works, and so do a few other things that weren't working in that version of the code. i've also replaced "ingots per reactor" with percentage of reactor's volume, so reactors are now filled according to their capacity instead of a fixed amount.

bad news is, i've discovered this. i'll wait for developers to respond and maybe fix this, in the meantime i have to work around this stupidity. basically, multiple storage containers don't work with the old code.

i've added a quick fix, so things should work now. the updated code is here, try it: https://pastebin.com/4xXT1ZZQ

 

Wonderful code. Will test it on my base. Do you run only in the main base or in each ship?

BTW, the only thing that I found weird was the name. You deserve having your credit, but BARABAS is an awful name IMHO, specially if you know religion. In Christian religion, BARRABAS is the name of the dude who is crucified with Jesus, and does not redeem itself.

I'd suggest the name AReA OS - Automatic Resource Administration Operational System. It's more commercial and palatable IMHO.

 

i'll be happy to hear any feedback and suggestions.

whichever way you want. i developed it to put on my every ship and on my base, so it's suitable for both (unless your ships are highly specialized, like Wico's autominer).

well, the name comes from a villain in a Russian fairy tale, Buratino (Russian adaptation of Pinocchio), nothing to do with religion also i'm not religious, so religious connotations don't bother me. whatever name you come up with, there's always some religion, some culture or some language where your name will mean "dick" or something else not pleasant

 

Fair enough, hahaha

 

Religion? I had actually forgotten that Barrabas was on the hill with Christ. I had assumed it was based on the character B.A. Barabbas from The A-Team.

I will be testing your script soon, once today's update comes out. Hopefully, my workshop scripts will be returned to me. Which brings me to a question: Do you think your script will interfere with other scripts on separate PBs, in this case, specifically power/battery control scripts? I also have plans to use the new LCD panels and other scripting to provide data to the users of my base.

Which also begs the question, are you planning to use the LCD panel instead of colored lights?

 

if those scripts of yors have nothing to do with refineries, assemblers, throwing out stone or moving stuff back and forth from ships, i don't think the scripts will interfere with each other. i don't use LCD screens in BARABAS, so no worries on that front either (although i thought about it). i'm planning to add support for LCD screens some time in the future, but they will probably have to be named BARABAS Something, so they likely won't interfere with any existing scripts either unless your script takes over all LCD panels regardless of their name. in fact, i'm almost certain that they would work similarly to how lights work now (i.e. a group of LCD panels).

 

Thank you for replying so quickly. I only use a very limited number of scripts, as I am not very experienced with the code, and don't wish to have conflicts. Currently, the only script my base is using (once I can get access to it again) is the power manager script I mentioned, which interacts only with batteries and reactors, and optionally an antenna, for diagnostics.

My suggestion for use of LCD panels was not quite the same as what you are thinking. Why use a group of panels, changing colour (I assume), when you could just use one panel and use text to describe any warnings? Or have I made the mistake of thinking that a script can change the contents of the LCD panel, when in fact that isn't possible?

 

well, my script does in fact touch reactors as well, but only for the purposes of keeping them supplied with uranium. so, depending on what your power management script does, they may interfere there. BARABAS doesn't touch batteries or antennas.

as for LCD panels, no, i was in fact thinking of outputting textual information. it's just i have to keep in mind that the text should be applicable to both small ships, large ships and bases, so i'd have to figure out exactly what to output, how to output, font sizes, etc. so it's not a small feature to add. why using group? same reason why i use a group of lights for color notification - you may wish to have notification in several places, so that you don't always have to hang around your only light/LCD panel to know something went wrong - you can have them all over your base/ship. whether you want one light/LCD panel or a hundred is up to you.

scripts can change contents of text and LCD panels (in fact, that's how BARABAS's configuration can optionally work), you're not wrong in that assumption.

 

Thank you again for responding quickly.

I should have said that the power manager script interacts with the reactor's state (on/off) only. It doesn't manage inventory.

My mistake, I assumed that you were using multiple lights to indicate status of different variables; i.e. one for refinery inventory fill state, one for cargo container fill state, etc. I did not consider having indicators in different locations, all providing the same data. I suppose I should actually look at your code before continuing this discussion...

 

it's no problem, i'll gladly explain any aspect of my script if you're curious about them - the code is 2500+ lines of C# code written by a C programmer (meaning, it's probably bad code to someone native to C#, not to mention it is not good code in the first place), so it's understandable that very few people would dive into it and find out the gory details. regarding your power management scripts, seems like there should be no conflict between your script and BARABAS.

but yes, i do use all lights to signal the same things - ALL of them go blue when you're low on uranium, for example. i plan to do the same for LCD panels, although as i said, i'm not yet sure exactly what information it will be outputting.

 

Well, my coding experience is in (Turbo) Pascal, circa 1990, so it may well be unreadable to me. Pascal and C are similar, but not nearly as similar as C is to C++ or C# or whatever they're calling it these days. On top of that, it has been more than twenty years since I've used that particular skill set...Hence my reliance on other people's scripts. I look forward to testing your script, and I hope you continue to churn out more.

 

i'm currently testing BARABAS's welder aspect "in the real world" (before "releasing" it i've mostly tested it in creative, hence the numerous existing issues in the original script), and i've hit a few things that i didn't think of when i wrote the script.

the biggest issue is, the storage is limited on the welder, but is much bigger on base. meaning, if i've got lots of assemblers and lots of components produced, the welder ship will get whatever it can get from base storage and it may not necessarily be what you currently need in order to weld. sometimes i end up having all the wrong items on the welder ship, but none of those i actually need.

i see two solutions to this problem - first, use a config file to specify which components to get and which not to. the upside is you can set your ship to download steel plates only and that's what it'll do every time you connect. the downside is (aside from a lot of coding) it'll quickly get tedious. another option is to turn off automatic components downloading by default and let the user manually get all the components from base unless he really wants otherwise. the upside is complete control while BARABAS will still fill the welders with your stuff, the downside is manual work every time you connect. i am leaning towards the latter approach as it's less complexity (staying true to original BARABAS's goal).

what do you think? maybe suggest any other solutions?

 

Version 1.1 is released, with numerous fixes and changes (all listed in changelog).

 

For welders:

Maybe you could allow a 'queuing' container(s) where the user can manually put components, and barabas will automatically pull/push from that container when the welder connects.

If all components in the base fit onto the welder, they should probably all get moved, regardless of where they come from...

 

it is currently not possible to know how much volume a particular item occupies, so i'd have to hard code everything if i want to calculate total volume of all components. i'm already doing that for ore, mind you, but that's an absolute necessity - not so with components. in other words, this is lots of mundane coding for little benefit and a very narrow use case. not to mention it is complex behavior, which is what i am trying to avoid with BARABAS.

as for "designated component container", the whole point of the script was to avoid all the different naming conventions and "special containers for X", so i would very much like to avoid any special blocks. this idea too doesn't quite fit in the idea behind BARABAS.

what i could do, however, is try and put things in separate containers automatically. i.e. if you have one container, everything will be put into one container, but if you have several, different things will naturally gravitate towards different containers. while this isn't a "designated queue container", it will sure help with hunting down all the components when moving them to welders, and also will generally help organize things.

 

yes plz, i dont care it puts all the gold ore in a random container, as long as it places everything in its own depending on how many containers are there (im thinking hardcoded categories like "ore, components, metals that become more split up depending on how many cargo containers are available)

 

i'm thinking more along the lines of "if 2 containers, separate components from the rest, if more - ore, ingots and components go into separate containers, prefer empty ones if overflowing". i don't see the need for further separation.

i'm also thinking of changing white alert to mean "out of some kind of material" rather than "out of gravel", to make it more useful (and to avoid situations where you don't have e.g. gold but find out about it only when you start assembling something). however, the magnitudes are rather different for different ingots - i.e. 10kg of platinum is plenty while 10kg of iron is peanuts. what are the ballpark values of "enough not to sound the alarm" for each ingot? so far i got:

Cobalt: 500
Gold: 50
Gravel: 5000
Iron: 5000
Magnesium: 100
Nickel: 1000
Platinum: 10
Silicon: 1000
Silver: 1000

Gravel is kinda tricky, because while it's generally not needed, once you decide to build a large ship large reactor, you can't accumulate enough gravel to build 2000 reactor components in one go because that's 20k gravel. Moreover, drill ships also throw out stone by default, so it would be hard to accumulate 20k of gravel in the first place. There are configuration flags to stop throwing out gravel added in v1.1, but switching off throwing out stone on both base and ship just to build a large reactor is kinda fiddly, so i would like to find a better way out of this situation. plus, we also don't want the base to constantly be on alert just because we don't have 5k of gravel when we don't even need it.

 

blizzerd and Wicorel, i invite you to test the opportunistic sorting (check either the pre-release link, or subscribe to BARABAS-next on workshop). due to how transfers work in SE, sorting will not happen at once, but the inventories will become sorted over time.

i've also went ahead and changed "white alert" to mean "we're running out of some kind of material". while this improves things, to determine exactly which material we're short on, one needs to check storage. i think this is a good opportunity to introduce support for status reports via text/LCD panels. i don't think i'll implement full-blown text panel for bases and ships just yet, as this functionality needs a lot of thought; however, reporting material shortages is definitely one of the things that will need to be present, so this will be worked on first.

first prototype (not yet uploaded):



(yes, that's 4 ships connected to base, all 5 of them running BARABAS)

 

Does your script still require a timer block? The first post says it does, but the script itself does not mention a timer at all. Have you implemented looping within the script?

 

sorry, yes, it still requires a timer. but every script that is run constantly requires a timer, so that's a given a timer is required to run the script, however the script itself doesn't depend on a timer in a way it depends on connectors or text panels for example - i.e. it can be any timer with any name, or any other method of running script for that matter (sensors, buttons etc.) - it's just that it's best to be run from timer. i'll mention that in the script though, thanks for pointing it out.