Dev Update: Objectives + Reserves and Population Races / Ethnic Groups Linked to it

  • Colony Simulation Model / Reserves:
    • [New: WIP] when a new colony is created, the initialization of reserves take now into account of the current composition of the population at the time.
  • Colony Simulation Model / Storage:
    • [New: DONE] each time that a reserve is updated (and used), the CSM calls the CPS to see if the reserve is used by a current CPS objective. 
  • Colonization Phase System (CPS) / Objectives:
    • [WIP => DONE] Provide A#Resource for #Period (PROVIRSRC): special initialization of the objective with its rules, calculations and specific data.
  • Population:
    • [New: WIP] add the rules considering how the reserves are used in a colony, according to which races and ethnic groups are present in it.
    • [New: WIP] each time the population of a colony is modified, the use of reserves is checked, since it can changes other the time.
As usual, the side-coding takes more time than the implementation of objectives themselves.To make systems and rules linked each other with one or multiples incidence can be seen as fine for a niche game like FARC but, on the dev side when a change occurs its repercussion must be checked and reported anywhere where it is relevant. If it is not done, the fact itself of trying to create a pseudo-simulation of game would be caducous.

Anyway, the implementation of multiracial / ethnic groups is pushed further since now the uses of reserves or not and their effect on consumption also depends on the composition of the population of a colony at a time T. It wasn't taken into account yet.

To take an extreme example; if a colony has only Artificial Intelligences as its population, any of the three reserves (food, oxygen and water) will not be used.
In the case of a mixed population, like a mix of baseline humans, non-sentient AIs, homo-provectus (a posthumans ethnic group), the use of the three reserves would be in force but the daily consumption would be calculated in proportion of the size each racial/ethnic group in this kind of population.

And since I working again on the CPS objectives, the use or not of these reserve can be important if a CPS objective use at least one of them to calculate its score (as it is the case already in the game).

Objective Provide A#Resource for #Period (PROVIRSRC) DONE...

...six or seven left to go. The 'six or seven" is because maybe I will discard the implementation of one of them for this release, or maybe not... yes not even a "fake" news.

I just completed the code of PROVIRSRC while I was in my lunch break @ job. So the most painful objective to write is done hehe. But yes, the whole isn't done yet.

Back to (the real) work, I will continue the dev tonight.

Dev Update: CPS Objectives + New Objective's Interface (w/ Screenshot)

  • Colonies / Storage:
    • [New: DONE] now, each time that a product is updated, the CSM calls the CPS to see if the product is used by a current CPS objective.
  • Colonization Phase System (CPS):
    • [New: DONE] the CPS now can keep track if a product, used by an objective, is updated. In the positive case, the linked scores are calculated.
    • [New: WIP] the system update certain objectives over the time, when their design request it. It is the case for PROVIRSRC which needs to keep track when its next period will end. 
  • Colonization Phase System (CPS) / Objectives:
    • [New: WIP] Ensures the Survivability of the Population (ASURPOP): special initialization of the objective with its rules, calculations and specific data.
    • [NOT DEV] Be Energy Efficient (ENERGEFF): special initialization of the objective with its rules, calculations and specific data.
    • [NOT DEV] Keeps the Usage of Line of Credit at Lowest (KEEPLOC): special initialization of the objective with its rules, calculations and specific data.
    • [NOT DEV] Keeps Alive #Percent of the Population at End Of Year (KEEPALIVE): special initialization of the objective with its rules, calculations and specific data.
    • [NOT DEV] Keeps an Acceptable Level of Mortality (KEEPMORT): special initialization of the objective with its rules, calculations and specific data.
    • [NOT DEV] Reachs a certain Level of Quality of Life (REACHQOL): special initialization of the objective with its rules, calculations and specific data.
    • [NOT DEV] Keeps Security at a the Allegiance Level (KEEPSECALL): special initialization of the objective with its rules, calculations and specific data.
  • Interface - Colonization Phase System (CPS):
    • [New: DONE] the old panel used to display the list of each objective and their score is now totally deprecated.
    • [New: WIP] the list of objectives is now displayed in the OpenGL view. It includes the score of each objectives and also specific data, if they have any.
  • Interface - Orbital Object / Colony / Energy:
    • [New: DONE] fix: if more than 100% of energy is used, it is now displayed.
  • Messages:
    • [New: DONE] Colonization: fix; name and full location are fully stored into the data structure of the message. Since a space unit can be remove by the end of the mission, if it is a colonization pod, it induced some errors in the informations of the message.
The implementation of the "Provide A#Resource for #Period (PROVIRSRC)" objective is finally nearly done, I just need to implement the rule and calculations when the end of the current period of time of the objective is reach.

Finally I changed the hardcoded data of the colonization pod to give them the ability to generate power outside of photonic energy, in other terms I equipped them with fission nuclear reactors.
The reason is that before, I only tested colonies on the same and one orbital object, Epsilon Eridani 2, which is pretty near from its star and lit but, once it given starting planets well farther than this one, star light is dim which in term of power generation .
The calculation of energy generation via photonic power take into account the illumination from the star, modifed by the distance, albedo and so on.

I also started the work on the interface, to display the objectives, by ditching the old CPS panel and integrating the display as HUD elements in the 3D view.
The not-so impressive work-in-progress is illustrated in the screenshot below:

FYI the third objective is the unfamous one I'm working on. It's title change according to the type of resource to produce and the period of delivery (each month, quarter or the full year).

I flushed many bugs here and here, many of them from the colonization mission itself. Also there were a problem with the removal of space units and the process of their tasks, it is fixed now.
Two big bugs stay for now, it is the loading of a game (from the Load Saved Game window) which is totally not working (certainly because of the changes with backstories and CPS) so I need to review the code. The second bug is when I start a new game when a actual game is ongoing.
Starting a new game from scratch, or continue the last one works, so it shouldn't be difficult to fix.

That's all for now.

Dev Update: Tasks Subsystem Fully Updated + Bugfixes + Finalization of Design for Space Units' Internal Structures

  • Missions / Colonization:
    • [WIP => DONE] the setup of the mission is fully fixed. There were problems with trip time calculations due to boggus deltaV given to docked space units.
  • Missions / Landing:
    • [WIP => DONE] fixed: the calculations were bogus due to the fact that the procedure didn't taken into account of docked space units (when they are used) and mixed data between the mother vessel and its docked ones. 
  • Space Units (in-game):
    • [WIP => DONE] dock/docking is replace by better terms of carry/carrying. That really specify space units carried INSIDE another one. There will be a docking ability, but nothing to do with it.
  • Time Flow System / Task Subsystem:
    • [DONE] complete application of modifications in the data structures of the tasks, according to the updates to mission and space units. Include a cleanup of the data structures themselves.
    • [DONE] fix: prevent a division by zero, in FCMgTS_TaskToProcess_TransfertToInProcess->Colonization Mission, during the calculation of acceleration by tick.
  • Time Flow System:
    • [NOT DEV] buttons are added to allow the player to end a turn directly by one tick (the standard turn), one hour, one standard day, one week and one month.
    • [NOT DEV] a basic framework for events buttons is now implemented. It can now "popup" special end turns button linked to special events that can occur over a game.
    • [NOT DEV] addition of the "end of next colonization mission" event button to end the turns until the next colonization mission is finished to be processed.
Working on the tasks subsystems were more work than seen, but it is done now and fully working.
The colonization mission is fully working again too.

Now I can finally put my entire focus to complete the implementation of data and score calculations, for all the existing objectives in the game. I already started it with "Provide A#Resource for #Period (PROVIRSRC)", and since it is the most complicated to develop, it will be completed first. the rest will follow.

Also, since FARC is now fully turn-based, I will add buttons to end turns of specific length, but also I will add a basic framework for future implementation of events end-of-turn buttons. Please read the todolist above for a (little bit) more informations about it.

I also finalized the design of the internal structures of the space units, because yes, one day the design of spacecrafts (stations, Bernal spheres and so on) will be implemented in the game.
Without telling much, since it will not be implemented before the basics of FARC are done, each space unit is based on an internal structure giving base data, like the overall shape (streamlined delta, cylindrical and so on), the architecture (basic function the framework tend to, like Deep Space Vessel or Stabilized Space Infrastructure), the dimensions of the spacecraft, the available volume and surface, and the maximum hull frame strength.

The overall shape defines how the available surface and volume are calculated and also define the hull sections, that will be used for hit location during a combat and also to locate the equipment modules.

The architecture of an internal structure define to which general optimized use a future spacecraft is destined to. There can be some variations from it, but the main vector is fixed.

They really shape the future spacecraft in the way that each equipment module is allowed to be installed into specific types of architectures.
This is used to keep a certain coherence between the shape and structural design of a space unit, and its realistic use on the field.

Outside of that I also started to finalize the space units' design too, especially one of its 6 keys elements: the hull.

This part will contain the set frame strength, the structural volume and mass, the structural points (sort of hit points), the acceleration limit and the final available volume.

It will have also a per-section data serie with: available volume and surface, structural points of the section and a damage chart.

I think I will stop the details here hehe, but the whole part I described is also fully final in the doc (and ready to be implemented... one day)

After this WOT, I thank you for your interest and... back to work.

Short Notice: Moving to a New Place (DONE) + Resume of Development

As the title said, I Am finally back on track in my new place.

I will resume the development tonight (EST time).