Remove CPU pool

[Xenega]

Instead of using a CPU pool for building project, add building project as a new task.

[Quix0r]

Love this idea. Then it is obvious what the CPU cycles are used for.

[PeterJust]

Good idea! This would also visualize the jobs progress, which is invisible at the moment. And it would be possible to throttle the spendings according to current capabilities. While at it: the slider for jobs is redundant, as overflow cpu is allocated to jobs anyway.

[shentino]

IMHO, barring you either:

a) not having enough CPU to go around even for basic maintenance, or b) having explicit user override

CPU (and for that matter) needed for maintenance of bases and whatnot should be spent on that first before it's made available for projects or research or construction.

also I'd like to suggest also that for cases of contention between two construction projects that combined exhaust the available CPU or money, prioritize whichever one is closest to completion, that way you get your bases up the fastest one at a time instead of waiting for them to slow-march in unison towards the finish line.

Plus it's not a good idea to let the list of in-progress bases to play random number roulette to decide which one gets their resources satisfied first. They should always be deterministically sorted somehow that doesn't depend on alphabetical order.

[nthykier]

I agree that it can feel very opaque to determine how bases are prioritized. Based on the code, here is the order:

1. Explicit job allocations consume CPU.
2. Maintenance (Cash) is paid.
3. CPU+Money is spent for research.
4. Maintenance (CPU) is paid.
5. CPU+Money is spent on construction of bases.
6. CPU+Money is spent on construction of items in bases.
7. Left over CPU is used for jobs.
8. The newly earned Money is used for Maintenance (Cash) if there was a deficient in step 2.
9. Bases are checked for normal discovery or death by lack of maintenance (note that maintenance deficiency is computed earlier; this is just where the code does the clean up sweep)
   • Bases ordered early are the bases that you risk losing.

Base order

Bases are always ordered as follows:

• Locations "by hash order" (which is poorly defined in python << 3.7, but should be stable within a game session; but not across save-load cycles)
• Within a location, it is ordered by when the base was constructed (when you clicked "New Base" for that base).

Item construction

• First bases are ordered as per above
• Items (within a base) is ordered by hash order. As understand it, in python 3.7 or later, this should be cpu, reactor, network and security in that order. For older versions of python, you get a unique order per base, which is unhelpful.

[shentino]

Looks indeed like it could use some work. I'd put maintenance first in all cases, and before research.

I'm sure that an advanced AI trying to achieve godhood would know better than to undermine its own self-sustaining plowback.

Even organic meatbags dump their calories into basal metabolism first.

[nthykier]

@shentino Indeed. Patches are more than welcome. If you want to improve this bit then you need to look at def give_time(self, time_sec, midnight_stop=True): in singularity/code/player.py, which handles the priority of resources.

For base and item order, we would need something entirely different if you want explicit control; that probably requires a rewrite of the task list to a prioritized list plus adding tasks for maintenance.