Here's a few bugs I still have on my list: Blocks of type IMyShipController (cockpits, flight seats, etc) have Inventories (block.GetInventory(0) works) but those inventory instances are not correctly linked back to the block (block.GetInventory(0).Owner is null). Hopefully this is already on your list since it's been reported a few times before. Code: List<IMyTerminalBlock> blocks = new List<IMyTerminalBlock>(); GridTerminalSystem.GetBlocksOfType<IMyShipController>(blocks); Echo(""+blocks+":"); Echo(""+blocks.GetInventory(0).Owner); That should print the block name twice, but it only prints once because the Owner isn't set. There is no in-API way to discover the correct blueprint MyDefinitionId to queue into an Assembler to produce a given item; adding such a lookup would be fantastic but that is a feature request that was so far deemed impossible, so here is the related bug: calling CanUseBlueprint() with an invalid MyDefinitionId crashes the script rather than gracefully reporting failure. Code: List<IMyAssembler> asms = new List<IMyAssembler>(); GridTerminalSystem.GetBlocksOfType<IMyAssembler>(asms); MyDefinitionId blueprint = MyDefinitionId.Parse("MyObjectBuilder_BlueprintDefinition/SteelPlate"); Echo("?"+blueprint); Echo("="+asms.CanUseBlueprint(blueprint)); blueprint = MyDefinitionId.Parse("MyObjectBuilder_BlueprintDefinition/invalid"); Echo("?"+blueprint); Echo("="+asms.CanUseBlueprint(blueprint)); The first test succeeds because SteelPlate is a valid blueprint. But in the second test, Parse() returns a MyDefinitionId object even though the definition string is wrong, which makes it impossible to know in advance that the following CanUseBlueprint() is going to throw an exception with that invalid definition object. So either Parse() needs to return null for invalid definition strings, or CanUseBlueprint() needs to gracefully return false on invalid definition objects. I haven't re-tested this in awhile, but I have in my notes that inven.TransferItemTo() gives a pretty useless return value. Transfers can report success when in fact zero items were moved because the destination was full, or the destination does not accept the item type, or possibly other errors. It seems like TransferItemTo() only reports connectivity, but there is already IsConnectedTo() for that purpose (and neither cover situations like conveyor tube size or conveyor sorter whitelist/blacklist restrictions). Thanks!