As usual the development takes more time because I have to push the test for certains objectives.
For example, Provide #Period A#Resource; a colony must provide a A#Resource for its faction of allegiance. A fixed volume of A#Resource is taken at a specified #Period.
The logic seems basic at first, we just need to know how much resources are available in the game, select one randomely and generate the rest of the objective's data.
Well not so fast... What happen is the player start on an icy asteroid and the objective ask him to provide uranium ore? That would certainly pose a problem. Same if water is asked and the player start on a liquid methane world, like the Saturn's satellite Titan.
Of course we can imagine to develop certains way of production and refining, but as a reminder these objectives are for the early game when the player has pretty limited manpower, infrastructures and usable technology.
For that purpose I creating a Environment Resources Class List (sorry for the pompous name) that contains all the tests relative to the orbital object of destination for the players colony. It takes into account the following data: the orbital object type, its environment (Space, Restricted or Free), its atmosphere and its hydrosphere.
So in the end a custom list of resources is created and will be used if one iteration of the Provide #Period A#Resource objective is called.
There is a second objective, Reach a Capacity of Production, that can uses not only resources but also any of the other classes of products.
This one can be simpler because the list of possible products is based on strategic wants of the Factions of Allegiance.
Of course since again it target the early game, the products to produce can be resources, refined products or manufactured ones (on a crude level).
Normally a colony should be able to generate with more or less difficulty these products, and since a backstory can automatically reject certain objectives, the configuration of colonies that cannot doing basic industry shouldn't be concerned.
The designing and coding of all this requires certain documentation cross-over between the main document, the list of CPS objectives and the products. But it is doable.
All that to only generate objectives that can be plausible and not completely random to a failure.
Rest assured that the rest of the objectives doesn't requires such convoluted logic and are more easier to code than the two that have been exposed in this post.
So that's all for now, a lots of talk for sure :)