Scripting: Access to game definitions

Currently the scripting API does not expose any of the game's loaded definitions. This means for many use cases we have to extract and maintain a separate copy of these definitions for the purpose of handling production queues, optimizing refineries or fetching required components for projections from inventories. No sinlge entry point into the API makes this more clear than IMyProductionBlock.AddQueueItem() asking for the ID of the blueprint we want to use with no way to query what is available.

But it doesn't stop there: Refinery speed and yield of ores, the performance of thrusters and many more require knowledge of the definitions of cube blocks, blueprints, ores and components.

Existing scripts work by extracting the data from the game files and storing a copy of sorts in the code. This has the 3 major shortcomings of 1) becoming outdated when a new game version adds or changes definitions, 2) not accounting for loaded mods, 3) bloating the code size considerably. It is also an error prone process.

An argument against access to definitions may be that it works against the idea of the PB running inside the game world without immersion-breaking access to meta information about it. I would distinguish between two categories here: A) information that the engineer can already access at a fingertip through the game interface and B) information on the game world that they have to discover on their own. An example of A would be lists of blueprints in production blocks or the components required for any cube block. An example of B would be the atmosphere and gravity on any planet in the world. The gray zone would be made up of things like "the conversion rate of iron ore to ingots in a basic refinery" or "the thrust of a large grid small H2 thruster". Depending on how you look at it, these values are either implied to be known (cat A) or part of the player's discovery process (cat B). You can see the line blur when you think of someone sitting down to write a script that displays the ore requirement for 10 reactor components - not an uncommon taks for a general production script. IMO, all the block performance stats and blueprint details would ideally be accessible for best flexibility. Thanks for reading!

Best regards,

Marco