Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
By the way, it says: "assembly not found. Compile the script".
90% of my own scripts is broken after update
for [Inventory Management] is it possible to set a priority and needed amount?
If this would be possible this would be a gamechanger for me ;)
Sorry for the delay. It sounds like you have the script set to use everything it can touch. There are a couple of options in the initial setup and one of them is "only this grid"
My building is done with its queue, but my vehicle is empty. My vehicle is pulling ingots and assembling parts it needs. The building sees that through the assembler, and then starts pulling the components into its inventory. The building is now above its queue, and starts to disassemble.
The building pulls components into its assembler, which the vehicle now sees and steals. Now the building is below its queue, and starts assembling again.
Rinse and repeat a couple times and I shut down the vehicle's manager, and now the building is disassembling 500 gatling gun boxes
Just a hunch. I also noticed that the assembled components in my vehicle weren't being stolen to disassemble by the building, so at least that's working right.
Unfortunately, I have to disable the control programs every time I park otherwise my large grid mobile construction vehicle and my small grind vehicle printer are going to throw themselves into an endless cycle of assembly and disassembly.
They have their own unique production group tag, they're both set to use only their own grid (setting it to false didn't change any behavior) and they both have fully tagged/sorted blocks.
The only thing I can think of is that the script is collecting components from the other grids, depositing them, then freaking out and destroying them because its above quota. Then because the other grid's components are all gone, that grid starts assembling replacements. They both do this to each other endlessly, and the sound is quite obnoxious
Thankfully, that means they aren't automatically disassembled. Unfortunately, that means I can't automatically produce them.
Its very low priority, I suppose, and if I combine some other scripts I have to dig up the item names I could manually add them myself If I cared to, but just reminding you anyways.
I won't need to automatically manage their existence but having flare gun ammo automatically build would remind me that I need to load my flare launchers.
Any chance you would still implement such an option? Would be neat if a carrier docks and all the designated storage on it and its parked or connected subgrids would be refilled automaticly up to a defined fill lvl. Maybe even reducing ammo on turrets so if they get shot the ammo exploding there doesn't do more damage than the actuall hit ^^.
You need to place a Programmable Block and then enter the terminal for it and select Edit -> Browse Scripts and then look for it in the list that shows
https://steamcommunity.com/sharedfiles/filedetails/?id=3189047555
Send me the world so I can see what's going on
Negative.. are you having an issue with it?
Just add all of the blocks you want included to a block group and use that option
Try tagging the LCD per the instructions in the PB Custom Data
I had to completely wipe the custom data and the script itself, i.e a fresh install, which was painful but at least it works now lol.
Amusingly it was juggling the gatling gun ammo in and out of itself when trying to disassemble it. I think it may have been stealing all of the ammo from the turrets, and the turrets were eating it all back and it caught itself in a loop? I was wondering why I set the ammo cap so high.
Something to do with switching between assembling stuff and disassembling stuff? It seems to like defaulting to disassembly, and if it does successfully queue something in between me pressing recompile, I have to manually switch over to the tab it wants to be on to do that work.
Well it finally ran out of assemble and disassemble tasks, but its still stuck.
Okay, all fixed :)
It's possible something broke with the major update. I'll run a check and see.
I think its stuck trying to adjust the queue. Best I can get out of it is a sudden update of the assemblers before it dies again.
It does not help that I recently changed pcs but moved the data over, nor does it help that I'm currently trying to add designator batteries (Ace_DesignatorDummy) to the queue list. Incidentally, adjusting the queue is what causes it to break. It can momentarily add the entire order to the assembler, but if it needs to change (say to disassemble something) it breaks.
Its also broken on an older blueprint.
The error isn't very readable.
Exception Message: Object reference not set to an instance of an object
Stack trace at: Sandbox.game.entities.cube.myproductionblock.addqueueitemrequest(myblueprintdefinitionbase)
and so on.
Hmm. I will look into what can be done. More to follow :)