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

- fix colission...
	a chance now, by making sure it excludes the other mover (pathC)
	exhaustive tile-by-tile check of the entire bb helps, but still allowing stuck pos
	fix tile aabb calc for circle, fixed

V3 features a super simple physics system (anything that moves has a velocity vector and that’s it), and with it also comes an (optional) super simple collision system. For now it is enabled for every entity that has a PhysicsComponent and doesn’t have a PathComponent. This means an entity can be put “on rails” under demand and ignore collisions, which will be very useful later on for certain objects.

- fix path system
	handle nonwalkables while pathing
	quick isWalkable check with 0 phase
		new boundary checker in TMS with fast shortcut for small circle bounds

PathFindingSystem continues to be refined and optimized. A fast 4-sample shortcut was put in place for entities that have a small circular boundary, instead of doing a fully precise boundary-tile checking.

- unstuck system in collision
	to catch building an object over an nonpath ent for example
	stuck counter in phyC, since only phys movers can be stuck
	after 5 stuck ticks does a full map spiral search, warps when tile found

Another improvement to TileMapCollisionSystem adds checking for stuck entities. A “creative” user can, for example, plant a blueprint object on top of an walking entity and get it stuck under it. The system can now detect this situation and automatically warp the entity to a safe, nearby tile.

- test: doors that visually open/close when any matching entity croses
	remove wall door tiles
	then change existing doors to be objects
	DoorC/DoorS in c++ for max speed (phase 0 system)

Another small gameplay system, added at this point to test other systems. Like other phase 0 systems it was done in C++ for maximum efficiency (phase 0 systems run their logic on every entity they subscribe to for every frame, so they are usually done in C++. Scheme systems should be designed for gameplay that accepts a phase of at least 5, so they will check an entity every 0.5 seconds as a minimum).

- system: jobs and job seekers (C++)
	use references and childC, works well
	BusyC
		ref to subj ent, both for job ent and worker ent
	BusySys
		remove BusyC when subj is invalid
	JobC
		implicit state for now
		abstract progress
			ticks progressed, logic on done/not done in other places
			optional max tick provided for jobs with a definite time
		desired pose for workers
	WorkerC
		aspect for valid jobs
	WorkerSys
		seeking job beha for workers, if not busy find the closest matching job
	JobsSys
		keep track of assigned worker (via busyC)
		increment progress if worker on job area and set pose
		try to path worker to job area if away
	interruption support? like being attacked, walking to job and slipping, etc ---> remove BusyC

The big one for the past week. V3 now has a generic collection of components and systems for performing V2-style jobs. This deals only with the basic mechanics: the existence of entities that are jobs, their current state, and act of looking for a job and pathing to it, and the act of staying in the work area until it completes. Notably missing are the spawners of those job entities and the code for dealing with the job results. In V3 this must be handled by separate systems, thereby making the base job system as generic as possible.

- move officer entity maker to scheme
- introduce a "finalizer" for officers inserted into the station, since some comps are now scheme-only
	will need to rethink this pattern in the future, tie into future job metadata model

Officer entity creation has been moved to Scheme to enable scripting it.

- system: object building (scheme)
	building must be under construction mode somehow
		tool add a construction-object-component w/o ent ref, picked up by sys later on
		tool apply tint/opa
	station-object-build-system
		monitors all buildings with construction-object-component
		checks job ent to see if valid (could be suicided by floor destroy for example)
			it is created if needed
				it is children of building
				has construction-job-component plus everything else needed
					4-side decide
		checks job ent to see if completed
			when completed removes job ent, tint/opa, construction-object-component, adds impassable

Constructing new objects now has a specific job, and the required systems and components were implemented.

- system: floor building (C++)
	TileMapBuildSystem
		phased scan of entire tile map
		when tile is bit constructing and nearby (4-dir) walkable, plant job entity
			how to make sure it's unique?
				get all job ents in 9-area (so single query), make sure none is floor building for this tile
			how to kill job ent when tile is removed? no child possible
				sys also checks on jobs ents to see if still valid

As with objects, building floors is now based on a job. This was done in C++ because tiles have no entities to represent them, by design. So this system requires a (phased) scan of the entire tilemap to detect under construction tiles and spawn the required jobs where necessary. Checking a few hundred tiles per frame is not slow but it’s better to use the scripting time slice budget somewhere else.