Taleden's Inventory Manager [TIM] User's Guide

This guide includes complete documentation and instructions for Taleden's Inventory Manager [TIM] for Space Engineers:

http://steamcommunity.com/sharedfiles/filedetails/?id=546825757

TIM is an in-game script which can help to automate the management of your inventory and industry. It can sort items into various containers according to your prioritized preferences, make sure your Refineries are always focused on the Ore you need refined most urgently, and manage your Assemblers to keep a balanced supply of Components on hand at all times.

Donations

TIM is and always will be free; donations are not required, but if you like the script and would like to support my development of this and other tools, feel free to contribute via PayPal[www.paypal.com].

Installation

Simply load the script into a Programmable Block, set it to run every few seconds, and away you go! If you're not sure how to do that, follow these steps:

• Build a Programmable Block and a Timer Block and make sure they're powered and owned by you.
  
• Open the Terminal, select the Programmable Block and click "Edit" to open the Code Editor.
  
• Click "Browse Workshop", select "Taleden's Inventory Manager", and click "OK". You can also just copy the entire script onto your clipboard and paste it into the Code Editor.
  
• Click "Check code" which should result in "Compilation successful."
  
• Click "Remember & Exit".
  
• On the Timer Block, click "Setup actions", drag the Programmable Block to the first slot and choose "Run with default argument". Then drag the Timer Block to the second slot and choose "Start".
  
• Set the Timer Block's Delay slider to a modest value (I use 5 seconds).
  
• Click "Start".

For Users of the "Automated Inventory Sorting" Mod

If you're currently using the Automated Inventory Sorting mod, you probably already have dozens of tags set up on all your containers. To give TIM a trial run without having to change any of those tags, simply put "norewrite prefix=" (without the quotes) in the Argument field of the Programmable Block. This will disable TIM's tag prefix so that it recognizes your existing AIS tags (i.e. "[Ingot]" instead of "[TIM Ingot]"), and it will disable TIM's tag rewriting feature so that your tags will be left as-is in case you decide to switch back to AIS. Just remember to disable AIS while you're testing TIM, so they don't fight each other over where to put your stuff.

If you decide to make the switch to TIM, then you'll at least want to remove the "norewrite" argument so that you can benefit from TIM's tag rewriting to let you know when a tag wasn't understood. It is also strongly recommended to re-enable tag prefixes (either by adding a prefix to the "prefix=" argument, or by removing the argument entirely to use the default prefix "TIM"). There are many other mods and scripts that rely on tags in block names, and prefixes are a great way to keep them all from interfering with each other. When you set the prefix you will have to go back and add it to the beginning of all of your existing tags, but in the long run it will be much better for compatibility.

Name Tags

Almost everything TIM does is controlled by tags in the name of various blocks. Tags are enclosed by "[" and "]", and can have any number of rules in between, separated by " " or ",". Each rule begins with a keyword or item type and/or subtype, and some rules can have additional fields separated by ":". If a tag prefix is set then the tag must also have the prefix at the beginning or else TIM will ignore it. The default prefix is "TIM", but you can change or disable it by running the script with the "prefix=" argument.

For example, this tag uses the default prefix and two rules to request 100 of each Component plus 1 of each tool and weapon:

[TIM Component:100 PhysicalGunObject:1]

Tags are case insensitive and may use abbreviations as they're unambiguous. After parsing a tag, TIM can optionally write it back to the block name in a standard style; this feature is enabled by default, but you can disable it by running the script with the "norewrite" argument. Tag rewriting is an easy way to make sure it was understood correctly: any part of a tag that TIM doesn't understand will be changed to lower-case so that you can correct it. For example, this tag:

[tim Comp:100 PH:1]

will be converted into this:

[TIM comp:100 PhysicalGunObject:1]

because "comp" could mean "Component" or "Computer", but "ph" can only mean "PhysicalGunObject". Adding the "o" to "compo" will resolve the ambiguity, and then TIM will change it to match the first example.

You can also use tags in the name of block groups and TIM will apply them to every block in the group which does not already have a TIM tag of its own. Note however that tag rewriting is not supported for group name tags, so you may want to check your debug Panel (see below) for tag errors. Also note that if a block belongs to more than one tagged group, only one of the group tags will be applied (at random).

Tags can mean different things for different blocks, so each of the following sections includes further details and examples of how tags can be used to control TIM's various features.

Item Types and Subtypes

Space Engineers organizes all items into a few general types, within which each specific item has a unique subtype name. TIM can theoretically handle any type, but you will usually be working with just four: "AmmoMagazine", "Component", "Ingot" and "Ore". When referring to a subtype, you only have to specify the type if there's some ambiguity; for example "SteelPlate" is only a "Component", but if a tag says "Iron" then that might be the "Ingot" or the "Ore". In that case you may have to add the type prefix with a slash ("Ingot/Iron"), unless TIM can guess what you mean; for example, since a Reactor cannot contain Ore, TIM knows "uranium" in that context must mean "Ingot/Uranium" and not "Ore/Uranium".

TIM starts with knowledge of all items from the vanilla game, but if items are added by mods or future game updates, TIM will learn about them when it sees one for the first time. So it should automatically support any item, as long as you have at least one of them in a container that TIM can see.

Inventory Panels

If an LCD or Text Panel has a tag with the "INVEN" rule such as "[TIM INVEN:Ingot]", then TIM will use it to display a table of your current inventory of one or more types of item. You can display inventory for more than one item type on the same Panel by listing them in the tag, such as "[TIM INVEN:AmmoMagazine:OxygenContainerObject:GasContainerObject]". If the tag lists no item types such as "[TIM INVEN]", then TIM will display all items of all types. This can be handy for learning the type and subtype names of every item, but it will be an extremely long listing which may be difficult to read without SPANning (more on that later).

The first column of the table contains a visual progress bar depicting the current inventory total compared to the effective quota. The second column identifiers the item subtype (such as "SteelPlate"), and the third column shows how many production blocks are currently producing more of that item; for Ingots and Ore this column is labelled "Ref" for Refineries, and for everything else it's "Asm" for Assemblers. The last two columns show the numeric inventory tally and the effective target quota (more on that below), except for Ore: since Ore itself doesn't have a quota (only Ingots do), the last column of an Ore inventory table instead shows the maximum quantity that has ever been seen since the last time the quantity was zero. This allows Ore progress bars to steadily tick down as the Ore is refined, and then go back to full when a new batch of Ore is brought in.

A "!" next to the "Ref" or "Asm" value indicates that although the item is first in the queue of one or more production blocks, at least one of those blocks is currently jammed and not actively producing the item. For Refineries this is usually because the Ore was just assigned and the Refinery will begin work momentarily, but for Assemblers it can also mean that production has halted because a required Ingot has run out. When an auto-managed Assembler is jammed this way for 3 consecutive TIM cycles, its queue will be cleared and the jammed item placed on hold from automated production for a period of 10 to 100 TIM cycles, depending how many times it has jammed recently; items which are on hold in this way show "-" in the "Asm" column. For more on the job assignment and jam resolution behavior of TIM's Refinery and Assembler management, refer to those sections later on.

Quotas and Quota Panels

If an LCD or Text Panel has a tag with the "QUOTA" rule such as "[TIM QUOTA:Ingot]", then TIM will use it to display a table of the quotas for one or more types of item. As with inventory Panels, you can display (and control) quota settings for more than one item type on the same Panel by listing them in the tag such as "[TIM QUOTA:Ingot:AmmoMagazine:P2]", and all types will be displayed if no types are specified.

Each section of the table begins with an item type header, and each other row shows an item subtype followed by its minimum quantity and target percentage. You can edit the numbers in the table and TIM will read them in the next time it runs, but will only apply quota settings for each item according to the priority of the quota Panel(s) containing that item. Quota Panel priority is set by adding a ":P#" to the tag rule, such as "[TIM QUOTA:Ingot:P5]" with lower numbers having priority over higher numbers. If an item appears on multiple quota Panels with the same (or unspecified) priority, the higher quota settings will be applied for that item.

The minimum quantity for an item is the most conventional kind of quota: the absolute least quantity that you want to have on hand at all times. For this reason, the minimum quantities that TIM uses by default are fairly low, so that they're appropriate even at the beginning of the game. The default minimums are generally just high enough to cover the cost of at least one or two of any kind of block.

As you amass more resources, however, you will probably want proportionally higher quotas, and this is what the target percentage is good for. This kind of quota is applied to the quantity of an item as a portion of all items of that type, so that it continues to be appropriate even as you gather and produce more and more items as the game goes on. The default percentages are based on a materials analysis of six blueprints which are built-in to various game starting scenarios (Green Station, Blue Ship, Red Ship, Builder, Fighter, and Miner), plus a handful of other popular blueprints published by the community.

There is also a third kind of quota that is not shown on the quota Panel, which is the sum of all limited requests for an item. This is a good way to cover things like ammunition and fuel: when you build more Turrets or Reactors, instead of having to update your quotas you can just give those new blocks a suitable item request tag (see below) and TIM will treat those as implicit quotas, to ensure there's always enough fuel and ammo to go around.

After applying all three of these types of quotas to a given item, the highest of them becomes the effective quota, which is what's shown on the corresponding inventory Panel (discussed above) and used to govern Refinery and Assembler management (discussed later on). For example, suppose you have 1000 Iron Ingots plus another 500 Ingots of various other subtypes, three Cargo Containers which are all tagged "[TIM Ingot/Iron:400]", and the default Iron quotas (200 and 88%). The three Containers have a combined implicit quota of 3 * 400 = 1200, which will override the minimum quota of 200. But the target percentage yields an even higher quota: 88% of 1500 total Ingots is 1320. Therefore, the effective Ingot/Iron quota would be 1320, and the Ingot inventory Panel would show an Iron quota of "1.32 K" and a progress bar which is about 76% full (1000 out of 1320).

Panel Spanning

Inventory and quota Panels may also be tagged with the "SPAN" rule, which allows one table of data to be spread out over a set of separate Panels. For example, "[TIM INVEN:Component SPAN:3:2]" will use six Panels (3 wide, 2 tall) to display your Components inventory. SPANned Panels must all be of the same type (all regular LCDs, all Wide LCDs, or all Text Panels), and only the top-left Panel in a set should be tagged. Font sizes of SPANned Panels will be set to match the top-left Panel, and font sizes on all types of Panel outputs will be automatically reduced if necessary to fit the displayed data.

Status Panels and Script Complexity

A Panel tagged with the "STATUS" rule as in "[TIM STATUS]" will show information about the last few executions of the script: the total run counter (since the last time the script was recompiled or the world was reloaded), the script step for that run (which depends on the "cycle=" argument, described later), complexity load level, the number of item stacks that were transferred, and the number of managed Refineries and Assemblers that were assigned to do some work. Status Panels cannot be SPANned.

The complexity load is also displayed in the terminal window of the Programmable Block after each execution, and it is of particular importance since if it ever hits 100% the script will crash with the error "Script execution terminated. Script is too complex." To avoid this problem you can add "cycle=#" to the Argument field of the Programmable Block to divide up TIM's work across multiple executions; for example "cycle=5" will cause TIM to do roughly 1/5th of its work on each run, which means it will take 5 runs to complete one "cycle". You can increase this value until the script runs and the complexity load is reasonable (ideally under 75%), but it can only go up to 11; if you still get complexity errors at that point, you'll have to find other ways to reduce the amount of work TIM has to do. Some strategies for this are to use more specific item sorting tags (i.e. use one dedicated container per item type rather than dividing your Steel Plates among many containers), removing Panel SPAN rules, or eliminating some inventory or quota Panels entirely (since performing column alignment for displayed tables is surprisingly "complex").

Debug Panels

A Panel tagged with the "DEBUG" rule as in "[TIM DEBUG]" will show detailed messages about things such as script arguments, docked grids, any tag rules that were not understood (which is especially helpful if tag rewriting is disabled), and whether any items could not be sorted as requested because of missing conveyor connections or full containers. If something isn't working as expected, it's a good idea to start by defining a debug Panel and see if it provides any clues. Debug Panels cannot be SPANned.

Item Sorting

Most blocks with an inventory may be tagged with any number of item types and/or subtypes in order to sort the specified item(s) into that container. Collectors, Drills, Grinders and Welders are ignored by default since they usually work best by using their built-in conveyor behavior, but they can be enabled using the "scan=" script argument (discussed later on). Each request may optionally have a priority (a "P" followed by a number) and/or an amount (a number with an optional "K" or "M" suffix). For example, this tag requests 1,500 Steel Plates at priority #1:

[TIM SteelPlate:p1:1.5k]

If the priority is omitted, it is treated as the last possible priority (or, technically, a number somewhere north of two billion). If the amount is omitted then the request is unlimited and the block will take as many of the specified item(s) as it can.

Item sorting requests are honored in priority order (starting with 1, then 2, etc), except that all limited requests are honored before any unlimited requests. Consequently, these three tags will be honored in this order:

[TIM SteelPlate:P5:100]
[TIM SteelPlate:P1]
[TIM SteelPlate:P2]

Since the last two requests are both unlimited, the third one won't get any Steel Plates unless the second one can't for some reason (such as if it's full, or a conveyor connection is missing).

If the tag contains more than one rule that applies to the same item at the same priority, then the later rule overrides the earlier one. For example, this tag requests 100 of every Component except Steel Plates (200), Gravity Generators (none) and Motors (as many as possible):

[TIM Component:P5:100 SteelPlate:P5:200 GravityGenerator:P5:0 Motor:P5]

This behavior is similar to the Automated Inventory Sorting mod's "Ignore" and "Override" operators (depending if the new amount is zero), but it is the default behavior for TIM so there's no need for a special keyword. Note however that the priority must match for rules to override each other; rules with different priorities are treated separately.

If several different blocks request the same item at the same priority and there isn't enough of the item to satisfy them all, then the requests will be honored proportionally. If the requests were limited, then each block will get the same percentage of its request; if they're unlimited, then each block will get an amount equal to the same percentage of the block's maximum capacity. This is similar to the Automated Inventory Sorting mod's "Split" operator, but it is the default behavior for TIM so there's no need for a special keyword.

Abbreviations will be resolved in the context of any restrictions on what a block can contain. This means for example that "[TIM Stone]" is ambiguous on a Cargo Container because "Stone" could be the Ore or the Ingot, but it is accepted on a Refinery because their input inventory does not accept Ingots, so it must be the Ore. TIM will also normally reject any item sorting requests that violate these restrictions, so even "[TIM Ingot/Stone]" will not work to send Gravel to a Refinery because TIM does not expect that to work. However, you can override this behavior using the keyword "FORCE", such as "[TIM FORCE:Ingot/Stone]", in case you're using a modded block that does not follow the normal rules for its type.

Locked and Hidden Inventories

By default, item sorting requests will be satisfied by pulling the specified items from any other block's inventory which did not have a higher-priority request for the same item. However, if a block has the keyword "LOCKED" or "EXEMPT" in its tag, then TIM will not remove any items from that block (but it may still add items, if the block has its own item requests in its tag).

Some block inventories are also automatically treated as locked so that TIM won't interfere with the block's function. These include:

• Oxygen Generators and Reactors which are enabled, functional, and do not have a TIM tag.
  
• The input (Ore) inventory of Refineries which are enabled, functional (welded past the red line), and do not have a TIM tag; the output (Ingot) inventory of untagged Refineries can still be emptied to satisfy Ingot requests.
  
• The input inventory of Assemblers which are enabled, functional, and do not have empty queues. The input inventory is usually the first one (Ingots), unless the Assembler is in disassemble mode, in which case it's the second inventory (Components) which is automatically locked. An Assembler's output inventory can always be emptied, and once its queue is empty then input materials will also be pulled from it to satisfy other requests.

Note that Oxygen Generators, Reactors and Refineries which have TIM tags are not automatically locked because TIM expects to be moving items in or out according to the tag.

If a tag contains the keyword "HIDDEN", then its contents will not be counted towards quota calculations or the totals displayed on inventory Panels. No inventories are hidden by default.

Refinery Management

Refineries (and variants like the Arc Furnace) which are tagged with the "AUTO" rule as in "[TIM AUTO]" will be managed automatically by TIM. Ore will be assigned to these Refineries according to the inventory level of the corresponding Ingot relative to its quota, such that Ingots which are the furthest under quota will be produced (possibly by several Refineries) before Ingots which are near or above their target quota. TIM knows that Arc Furnaces only accept certain Ores and will make use of them accordingly, and any auto-managed Refinery can be similarly restricted by specifying Ore subtypes in the tag, such as "[TIM AUTO:Platinum:Uranium]".

TIM will attempt to learn how fast each Ore is processed by each kind of Refinery so that it can pass out Ore assignments that will complete in roughly 5 TIM cycles (which may be 5 script executions or over 50, depending on the "cycle=" argument). This allows TIM to react to changing priorities without having to constantly shuffle stacks of Ore between Refineries, which would reduce efficiency by incurring delays for each Refinery to notice the change in its Ore supply. When TIM estimates that a Refinery will complete its assignment within 2 TIM cycles, a new portion of Ore will be queued so that work can continue without interruption. Conversely if TIM estimates that a Refinery has more than 10 TIM cycles worth of Ore, then the excess will be removed so that TIM doesn't have to wait too long before it can reassign the Refinery according to current priorities.

TIM's automatic Ore assignments are treated like unlimited requests at priority zero, which causes them to be resolved after all limited item sorting requests, but before all other unlimited requests. This makes it possible to partially override TIM's management by giving a Refinery a limited request for a specific subtype of Ore such as "[TIM Uranium:100 AUTO]". Then if any of that Ore is available, that Refinery will work on it no matter what the quotas say, but when that specific Ore runs out then the Refinery will go back to getting automatic assignments from TIM. If the AUTO rule is omitted as in "[TIM Uranium:100]" then the Refinery will only ever process the specified Ore type(s), and will sit idle if none of that Ore is available. Conversely, you can also set unlimited Ore requests on any number of containers and then they'll serve as an Ore backlog: TIM will still put all managed Refineries to work first, and then allocate any extra Ore to the containers.

Because TIM does not know of any use for Ore except to refine it into Ingots, TIM will continue to refine any available Ore even if all Ingots are at or above their quotas. If you want to reserve a quantity of Ore so that TIM doesn't try to refine it, you can use a limited quantity item request on some other container, such as "[TIM Ore/Stone:1000]". Because this request has a limited quantity, TIM will honor it first so that by the time it gets to Refinery management, that stack of Ore will no longer be considered available.

Assembler Management

Much like Refineries, Assemblers which are tagged with the "AUTO" rule as in "[TIM AUTO]" will also be managed automatically by TIM. Items will be queued on these Assemblers according to their inventory level relative to their quota, such that items which are the furthest under quota will be produced (possibly by several Assemblers) before items which are near or above their target quota. Auto-managed Assemblers can be restricted by specifying items in the tag, such as "[TIM AUTO:Explosives:AmmoMagazine]".

TIM will attempt to learn how fast each item is produced so that it can pass out assignments that will complete in roughly 5 TIM cycles (which may be 5 script executions or over 50, depending on the "cycle=" argument). This allows TIM to react to changing priorities without having to constantly cancel queued production runs, which would reduce efficiency by tying up Ingots in an Assembler that will not need them all. When TIM estimates that an Assembler will complete its assignment within 2 TIM cycles, a new job will be queued so that work can continue without interruption. Conversely if TIM observes that an Assembler has not made progress on its assignment for 3 TIM cycles (usually because a required Ingot has run out), it will clear that Assembler's queue and place the jammed item on hold for 10 TIM cycles. Items on hold are not considered for automatic production, and appear with a "-" in the "Asm" column on their respective inventory Panel. If an item continues to jam it will be put on hold for longer and longer durations, up to a maximum of 100 TIM cycles. When production is able to resume on a previously jammed item, the item will not be put back on hold unless it jams again, and the hold duration for future jams of that item will decrease with each successful production assignment.

Because TIM expects that you will want to grow your Component supplies as you amass more resources, it will attempt to produce up to 110% of each Component's target quota, but only if that Component has a target percentage (> 0%) and TIM believes that your Ingot supplies are high relative to your total Component supplies. This over-production will in turn cause your Components' quotas to scale up as TIM builds more Components. Conversely if TIM estimates that at least one subtype of Ingot is in short supply relative to your Components inventory, TIM may stop short and only attempt to build 90% of your Component's target quotas. These behaviors should generally lead TIM's automated Component production to stabilize at a point where it considers your Component and Ingot supplies to be balanced (which is calculated based on the average Ingot cost of each Component, weighted by the default Ingot and Component target percentages).

Redundancy and Fail-Over

TIM only requires a single Programmable Block (ideally with a corresponding Timer Block), but you may optionally install TIM on any number of additional Programmable Blocks on the same grid or other connected grids, and run them all simultaneously (from the same or separate Timer Blocks). With this setup, only one instance of TIM will be taking any actions, but the others will remain on standby. If the active TIM becomes unavailable for any reason, such as disabling or damaging its Programmable Block or disconnecting it from the grid, then the next TIM will automatically take over until the first one is restored.

Connected Grids

By default, TIM will treat all connected grids as if they were a single grid (so if you can see a block in the Terminal when accessed from TIM's Programmable Block, then TIM will also see that block and handle it like any other). In cases where you do not want TIM to access a connected grid (such as docking your ship at someone else's base), you can control this behavior using the "DOCK" rule of a tag on a Connector. This rule takes any number of fields, each of which is considered a "label" which must match the tag on the locked Connector in order for TIM to traverse that connection.

For example, "Connector [TIM DOCK:alice:bob]" includes two labels ("alice" and "bob"). If such a Connector is locked to another Connector which does not have a matching label in its tag, then TIM will ignore that attached grid. Note that if neither Connector has any DOCK labels, then they will be treated as if they have a matching label.

Continuing this example, let's suppose that "Connector [TIM DOCK:alice:bob]" is on a shuttle which is shared by Alice and Bob, while each of their carriers' own docking ports are named "Connector [TIM DOCK:alice]" and "Connector [TIM DOCK:bob]" respectively. The shared shuttle could then dock with either carrier and have its inventory managed by TIM running on the carrier, since the shuttle's Connector has a label in common with both carriers' Connectors. However, if the carriers were to dock directly with each other, then TIM running on either carrier would ignore the other, since "Connector [TIM DOCK:alice]" and "Connector [TIM DOCK:bob]" do not have any docking label in common.

If you have a debug Panel (described earlier), TIM will use it to report on any connected grids that it is going to manage by way of Connectors with matching (or missing) DOCK labels. The name of each such grid will be reported along with the name of the Connector at which it is docked, and such connections can be indirect; for example if TIM is running on a station with a docked carrier that in turn has a docked shuttle, the report might say:

Carrier docked to Station at My Connector
Shuttle docked to Carrier at Connector 1 [TIM DOCK:shuttle]

Script Arguments

Several of TIM's functions may be configured using script arguments, which should usually be entered into the Argument field on the Programmable Block where TIM is installed, but may also be set on (for example) the Timer Block slot which runs TIM's Programmable Block. Multiple arguments may be combined by separating them with spaces.

• cycle=#
  Sets the cycle length to #, which must be a positive integer. TIM will distribute its workload over this many script executions (up to 11) in order to avoid the script complexity limitation. Default: "cycle=1"
  
• rewrite
  Enables tag re-writing. This is the default setting, so this argument does nothing unless you've changed the default in the Advanced Configuration section of the script code.
  
• norewrite
  Disables tag re-writing. Recommended only when testing TIM as a replacement for the Automated Inventory Sorting mod, so that your tags remain intact in case you decide to switch back.
  
• tags=AB
  Sets the tag open- and close-delimiters to "A" and "B", respectively, which must be different characters. Default: "tags=[]"
  
• prefix=PFX
  Sets the tag prefix to "PFX". TIM will ignore tags which have the correct delimiters but do not begin with this text, in order to avoid confusion with other scripts and mods that use tags in block names. Default: "prefix=TIM"
  
• scan=type
  Enables scanning blocks of the specified type, which must be "Collectors", "Drills", "Grinders" or "Welders"; this argument may be repeated with additional values. These block types are normally ignored to save time, since they are often used in great numbers and their default conveyor behavior pushes all contents elsewhere anyway. Default: none
  
• quota=mode
  Sets the dynamic quota mode, which must be "stable" or "literal". The new default mode is "stable", in which percentage quotas are applied against a theoretical item type total which is derived from the median of the current subtype inventory ratios. The original "literal" behavior applies percentage quotas to the true item type total, but this can cause the effective quotas to become a confusing moving target in the case when a few items are produced or salvaged in large amounts.
  
• debug=type
  Enables detailed debugging of specific subroutines, which can be "quotas", "sorting", "refineries" or "assemblers". This can help to diagnose problems with these parts of the script logic, especially when other mods are involved.

[sleepy_tyranitar]

Has anyone compared the performance of this to that of Isy's IM script?

[Axe]

How do I stop TIM from constantly increasing the quota? I cant update it in the panels, and my assemblers set to [TIM AUTO] keeps draining everything cause the quota is ever increasing

[LudwigVon67]

Is it possible for an LCD panel to not show the quota and quota bar ? My screen is 60% used by this bars

[tj2g]

@Orion on the comment from Sept. 1st, 2019, thank you! I'm going to repost that link so others have it closer to the front of the comments.

https://pastebin.com/raw/jieB53Ba

[Berkys32]

TIM is programmed so it should know about ANY modded items. Ores, components, hand items or ammo. You just need to put it in inventory space TIM has access to.
Few comments back I posted how to get tag of item you want to know (ie. to set quota)

[Boobies]

Great script. Quick question: does TIM automatically 'know' the Flachette Rocket from the Hydra rocket launchers? If not, how would I go about setting it to keep levels of the Flachette Rocket to 10,000?
Same with the ammo for the MG50 point Atlas turret? Or anything new.. Cheers.

[JM445]

Ok thank's, let's remember dig out my rusty C# skills x)

[Berkys32]

The only way I know about is to edit script in programmable block (its quite straightforward)

[JM445]

I there a way to save manually set quotas ? Each time I reload tthe game, quotas are back to the default low values

[Berkys32]

How many % from number of all items it should hold. So more items you have bigger quota will TIM hold. Ie. if you have 10 000 components (all together) and iron plates are set to 50% TIM will try to hold 5 000 pcs of plates (that leads to more components, thus bigger quota and so on and on afaik)