Globally TIM 1.6 works fine.
Can you describe the behaviour of AUTO ? Because it does not work I expected it.
Also what does "!" mean on panels ?

But first, how to test it from the pastebin source code repository ?
copy-paste from pastebin gives me 102'565 characters > 100'000 for 2729.
In order to reduce under 100K I used Notepad++ and replaced "\r\n" by "\n". To do this you need to select the search mode "extended".
\r\n --> \n --> 99837 characters

The unexpected behaviour is following.
On refineries when I use AUTO (with or without other tags), it sometimes add 25K or more Ore.
Other times it adds tens or hundreds.
I can't figure the rule.

However I did not have time to test what happens when quota change. Maybe TIM will remove the 25K and replace by new ore?

Thanks for the note about the line endings, I didn't realize pastebin would do that. Hopefully the other beta testers are able to make the same line ending conversion, because I'm running out of places to compact the code without making it totally unreadable. If Keen doesn't raise the 100kb size limit I don't think I'll be able to continue development of TIM at all.

TIM's goal is to give each AUTO-managed Refinery and Assembler enough work to last for 5 runs of TIM (or if you're using the cycle argument, 5 complete cycles which may be up to 55 runs with cycle=11). It has to learn this by observation, however, so when TIM first starts (or the game is reloaded) it will pass out small assignments (5kg of ore, or 5x blueprint) until it learn which things are fast and which are slow. Eventually it should stabilize so that each Refinery or Assembler is getting a new queued assignment about every 5 cycles, which allows TIM to quickly react to changing priorities but also prevents them from running out of work to do in between runs. So it is normal and correct that a Refinery might be given only a small stack of Platinum (which is very slow to refine) but a large stack of Iron (which is fast); if TIM has had enough time to learn the refine speeds, both stacks should take about 5 runs of TIM to complete.

It may be problematic if you're testing TIM by running it manually, however, since that will imply a very long delay between runs which will cause TIM to keep increasing the job assignments up to its maximum.

Oh, and "!" in the panels is shown next to the "Ref" or "Asm" column and it means that at least one of the assigned production blocks for that item is "stuck" and not actively producing. For Refineries this usually means that it just then received the ore and hasn't started working on it yet, but for Assemblers this can mean that it doesn't have enough materials to begin construction of the next queued item. In theory I would eventually love for TIM to notice this and try to resolve it, but unfortunately at this point there's just no room left in Keen's 100kb limit for any new features.

About the AUTO and cycles. Maybe there is something to dig here.
In my test it gaves me 25'000 silver when my timer was 1s. Which is far above than 5Kg when TIM starts.
But when I changed to 10 sec and it was more about 50 or 250 (I don't remember).
Maybe when timer is too fast there is a glitch in the calculation that gives thousands of items.
I have "cycle=1"

Hey Taleden, with teh problem of code size, I used Notepad++ to trim both lead ind trailing spaces (Plus the EOL thing). Code dropped down to 93 556 bytes, an extra 7% :).

Pain in the but to have to keep a working code and the upload an uglier version. Also in teh old days they where lots of utilities around to shrink code, (we had 64k limits on editors speed of compile for libaries etc). They use to convert variable names to one and two letters remove all whitespace, delete all comments.

Hope it helps a little.
Cheers So looking forward to auto assembler.

MRIC, how long does it take your refinery to work through that 25kg stack of Silver? And if you open the PG, hit "recompile" and then restart TIM on the 1s timer, do you see the assigned Silver stacks grow again from 5kg up to 25kg+?

roygul, it's true that there are various ways I could try to pack TIM into fewer bytes, but I see them as poor solutions to a problem that shouldn't exist in the first place. If I had to run the code through a minifier all the time, development would be much slower because that's an extra step for every single little change I want to try making, and any time there was a bug I couldn't isolate I'd have to wonder if it was being introduced by the minifier. That all sounds pretty tedious to me and makes development more of a chore than I'm really interested in at the moment; on the other hand someone at Keen could simply spend 10 seconds changing a "1" into a "2" and the whole problem would go away.

@taleden I do not know, I did tests. Moving piles of 25K in containers then doing others tests.
Therefore I did not let it process. Though it would have been quite long because Ag is very slow to process. I wouldn't be surprised it would have taken 1 hour.
If I have time in the coming days I will do other tests.

Regarding packing the text, I agreee it is preferred to have a clean and easy code to read.
Especially for debuging but also for other people who want to read.

Thanks for the line end tip, MRIC.

Currently testing [TIM AUTO:Component] on an assembler that has 9 other (non-tagged) assemblers on cooperative mode between the station and connected ships.

The size of this array seems to routinely overwhelm TIM, since it's not queuing up enough to last to the next tick in five seconds. Only Construction Components (because of speed) or steel plates (because of quantity) seem to last. I don't want to tag all of them to automatically produce, though, especially the ones that are on a docked frigate. What do you recommend users to do?

I was surprised that [TIM AUTO] included low-tier tools by default. It makes sense why an all-encompassing parameter would include that, but I'm not sure if it's useful.

EDIT: How far do automatic assemblers go before stopping? I'm watching the quotas rise and wondering if it will go until it just runs out of ingots.

Taleden:

Is there a way you could upload the appropriate code and just make it known in the title that its WIP?

I don't know why, but I can't seem to follow the directions appropriately to get the code under 100k.

Meh. Also, friend me, I would seriously like to discuss something with you.

I hadn't thought of trying to tag one assembler and have it backed up by others on co-op; if anything though I would expect TIM to react by issuing bigger and bigger jobs to that assembler, since it will keep thinking that it blew through most of its previous assignment almost instantly (when the co-ops take part of the job). But in your use case what would be the problem of just tagging all the assemblers separately? Even if some of the occasionally disappear when the ship undocks, TIM shouldn't mind that too much, it will just proceed with the smaller set of managed assemblers until the ship returns.

TIM doesn't specifically try to produce low-tier tools, it simply tries to keep all assemble-able items at their quota, so if you have set a quota for low tier tools then TIM will make sure you have some. If you don't want any produced, you can either set their quotas to 0 (which is the default), or tag all your assemblers "[TIM AUTO:Component]" as you have done so that TIM won't use them to produce anything except Components.

The stopping point for Components is based on your ingot inventory level. The idea is that TIM wants to help you grow your overall resource level, but it also doesn't want to completely deplete your ingot supply in case you have a sudden need to produce something later on. So if you let it run, you should see Components slow down and stop at some point; I can go into the specific algorithm that governs that if you like, but as long as TIM's behavior seems reasonable in practice, that's what counts.

The issue for me with tagging a bunch of co-op assemblers is that they'd start behaving somewhat unpredictably; instead of blazing through a job given to the main assembler, they'd be busy with their own pursuits. I also don't want to use [TIM AUTO] on my frigate's assemblers while it's based out of a station, because I'd prefer for it to just take a chunk of the station's resources rather than having its own ratios throwing things off when not needed. If I just tagged them with [TIM] by itself, would it help anything?
It doesn't seem to be compensating by raising the job sizes, but I suspect that's because of a slight delay while the assemblers gather up the ingots for the job--during which they show as stuck with an exclamation point on the panel.

Ah, I see what you mean about the tools. I had a cargo container set for PhysicalGunObject and another one set for PhysicalGunObject:1. While I was checking a debug panel, I cleaned up the latter to specify quotas for AngleGrinder4 and the like. Without a specific quota on the first one, will it still generate any low tier tools?

Glad to hear it pays attention to ingot levels. I was worried about the idea of rockets being produced and eating all of my uranium, or running out of iron or something and coming back to a bunch of stuck jobs.

I'll go back and test tonight with just [TIM AUTO] now that I fixed those tool quotas and see where it ends up.

[TIM Auto] on my main base is behaving.
As I hoped, the more specific tool quotas eliminated the low tier tool behavior.
I set two of the co-op assemblers to [TIM Auto], which smoothed things a bit, but that seems to automatically turn off co-op mode. I'm hoping we can get more smooth ordering so arrays with large amounts of co-op assemblers like this work more smoothly.

I moved on to testing on an interplanetary ship that I have parked on the earth-like planet.
[TIM Auto] was behaving at first, then it started making thruster components and quickly ran through the entire (small) platinum supply. If I removed them from queue it put them back.
I tried editing the advanced config on the script to set thruster components' quota to 0, or matching the growth of gravity generator components. In both cases, [TIM Auto] no longer queued any components at all, even though others like motors were in demand.

Would you be willing to try just tagging all the assemblers individually and letting TIM disable co-op and manage them directly, just to see how it goes? If you turn off auto-save you can always revert if something goes wrong. :)

I'm still having a hard time understanding the use case for trying to combine co-op with [TIM AUTO]. I certainly see the appeal of co-op when manging assemblers by hand because it's easier to add one big job and have it distributed for you rather than manually adding jobs to each assembler. But the whole idea of [TIM AUTO] is to automate the whole process, and TIM is perfectly happy to manage individual jobs across any number of assemblers. Letting TIM control your frigate's assemblers shouldn't be any different, since whenever the frigate is docked TIM will just see it as an extension of the station anyway so it won't have its own separate quotas or anything, it will just suddenly make a few extra assemblers available to TIM, which it will happily use until the ship undocks again.

The situation with your interplanetary ship actually sounds correct, though maybe not intuitive at first. As I mentioned earlier, TIM's goal is to build components to meet your quotas, but it will push those quotas higher if it thinks you have plenty of ingots and it will also let components fall short of quota if it feels your ingot levels are getting too low. The catch in all of this is that TIM has no way to know what materials are needed to build each component (because the API doesn't make that info available and I didn't want to hard-code it), so if *any* ingot type gets severely low, TIM will stop production of *anything* (or more specifically, it will reduce the target quota level from 100% down to 50% depending on the lowest quota level of your non-Uranium ingots). But if you refine more Platinum to bring that level up again, TIM should slowly start to resume production on components (including Thrusters, though you can always change that quota if you don't want TIM to try to build so many of them).

Part of my reservation about putting all my assemblers on auto is because I'm also using a nanite factory that's enabled to queue assemblers. If it puts jobs in the queue, I want them done fast. The other part is the question of performance. Any idea whether multiple auto assemblers are more costly to performance than one and co-op?

Platinum seems like a problem for the way you're describing the auto assemblers. It will generally be low or zero in planetary use, unless you've brought a bunch down from orbit. I only brought a token amount, intending it to be mainly for tools. Can auto assemblers not be used at all unless you have stocks of all ingots? It'd be nice, for example, if you could use [TIM AUTO:SteelPlate:ConstructionComponent:InteriorPlate] early game.

By the way, why is the syntax different for [TIM AUTO]? One of the solutions I tried, just in case, was [TIM AUTO Thrust:0], but that obviously doesn't work.

I didn't realize the Nanite mod also passed out Assembler jobs, but they may actually work just fine together. TIM doesn't remove or alter existing Assembler jobs, so if it sees a Nanite job in the queue it will just consider that Assembler to be busy and ignore it until it finishes. Conversely if an Assembler is working on something for TIM, it should have at most enough work to occupy it for ~8 TIM cycles, so if a Nanite job gets queued up behind TIM's jobs, it should start processing within 4-5 TIM cycles on average. If you're willing to try it out and see what happens, it'd be educational for both of us I think. :)

I see your point about measuring ingot levels but I'm not sure how best to deal with that. For planetary bases you could just reduce your Platinum and/or Thruster quotas (or set them to 0) to more accurately reflect the relative amounts you want TIM to aim for, but you're right that that's a poor solution for early game when you don't yet have any of the rarer materials. On the other hand TIM should always try to produce at least 50% of every (non-zero) Component quota no matter your Ingot supply, so that may still work out fine. I think I'll have to start up a new survival world and play through it a bit to see how it goes in practice -- or if anyone else would like to try this experiment, I'd love to hear how it goes for you.

The syntax for the AUTO keyword is different because it's not really the same kind of specification as item sorting, so I opted to make them more clearly separate to avoid confusion. I can see about adding a shorthand for AUTO:everything-except-X, though, since you're right that X:0 has been a common way to accomplish that in the past.