Internal development notes, very slightly cleaned up and commented a week later.

TL;DR: more code cleanups, some systems for of planet resource extraction are now implemented (resource nodes, extraction objects, simplified logistics, automatic ship cargo transfers), the UI color can now be customized, and fixing a bad programming pattern before it is too late.

- another massive removal / commenting commit
	Surface, Skill, Avatar, Agent*, Mission are out, plus minor related stuff
	and their UIs

Another week, another huge amount of code deleted from V2. This is the biggest one, and it affected very core areas of V2, including the entire model for map surfaces, the skill and combat system, and the AI for anything that moved on screen. Part of those tasks are already being handled by new V3 code, and the missing ones, like the skills and combat, need to be rewritten anyway to use the ECS framework in V3.

- resource extraction
	an in-world system counts nodes within extractor range
		model in scheme side for Body
			key based on X-Y, data contains resource, room for more
	another system persists some entities (extractors for now) into model
		key based on X-Y, data contains a hint in the planet-persist-component
		obj model has the hint, reverse map built during gen
- filter by the correct resource kind in planet-resource-system-post-processSystem
	add to extractor obj model
	also add radius
- resource tick generation
	model for resource gathering, in scheme
		c++ Body::tick does hook call
	each tick increases the (body 'stock) resource -> amount map prop to the amount of covered resource nodes
		logic is out of ECS, works without ECS sim
	hardcode speed and max capacity for now, will depend on more constructions later on
- resource+ship galaxy logistics
	model for galaxy+ship resource transfer logistics
		need model ship inventory of some sort
- fix: resource list in ship view makes following UI disappear
	as usual, no intrisic sizing
	add support for parent widgets inheriting explicit sizing from their children
		use -1 for width or height
- try to re-enable resource filter for galaxy view
	scheme re-populates C++ side data when needed
- planet: logistics mini system for extractors
	pallet-like object
	adds to global planet capacity, not per-extractor
		extractors also provide a small capacity

The big task of the last week was to start the new resource gathering system. Just like in V2 resources are gathered from planets. But in V3 those resources are represented by node objects on the surface of the planet, instead of abstract icons in the galaxy planet window. Your officers must now build resource extractors: automatic machines that slowly extract resources from nearby resource nodes. Here’s an anotated video on how it works:

For starters the resource system from V2 has been ported to V3, and each resource has been assigned a few categories, to be matched by the correct extractors (fluid, biological, mineral). The model and systems to support this new gameplay were implemented, as well as new V3 concept: being able to build persistent structures on planets, that will still be here if you land on them again in the future (unless a pirate decided he didn’t like them, of course).

Some basic code for planet and ship logistics is now place. For now logistics in planets are meant to be simplified. Only pallets have to be built, which increase an abstract inventory capacity stat in the planet (similar to how the V2 station warehouse worked). Ships will also have limited cargo capacity, but for now there are no gameplay systems in place for it.

- make UI colors re-definable
- options section for UI colors
	store in options model

The GUI subsystem was already fully based on symbolic colors for most of the user interface, so it was easy to fix the few hardcoded values and make it possible for the user to pick a different color for the UI.

- fix now before it's too late: way too much model lazy initialization is creeping into scheme code
	body stocks, storage, persists
	ship stocks
	find a pattern for init and use it
		constructor-like on ::create: NO, it will be stomped by deserialization, which overrides the hasthable as a whole
		manual init on ::init: deserialization wont affect it, but NO: it's not forward compatible like C++ constructors, will still need defensive programming
		constructor-like but passing current value: much better since it allows merge, but still difficult to find the right moment in deserialization
			try call on Registry::create -> BridgeCPPOwned::unserialize
			try call on Persisting::afterLoad -> BridgeCPPOwned::unserialize
	then stop doing so much defensive (and predicate ...) and (or assumed-accesor default)

Dynamically typed programming languages like Scheme make it very easy and fast to model your data as you go. While this is good for iterating fast over a feature, it can lead to brittle code. A usual anti-pattern is to include guards before you access some bit of state that may or may be not be there:

(display (or (table member:) "default"))

This will print default when member: is not a key in table. While this may fine for user provided data (a config file, a file downloaded from a third party, the input from a UI control), accessing fully internal data and structures like this is a very strong indicator of the code being in a bad shape.

A constructor-like pattern was implemented for the Scheme-side dictionary that C++ objects provide. This way, when a C++ object is created, there’s a chance for a Scheme-side proc to also initialize its dictionary.