UI overlays
I changed the different views to be rendered as overlays above the planet.
I also added titles to the overlays so it becomes more clear what the purpose of a view is.
Relative render depth
There was no way to set relative Z
or Depth
values for rendering (this determines if an object is rendered above/below another one).
Initially there was only
pub enum DepthLayer {
Default,
...
Effects,
EffectsTop,
TechOverlay,
Fixed(f32),
}
which made it practically impossible to have relative Depth
relationships without keeping track of the current value and using Fixed
.
For example the Item
s on a Belt
should always be rendered above the Belt
.
I introduced new types to allow setting both relative and absolute Depth
values
pub enum Depth {
Absolute(DepthAbsolute),
Above(u8),
Below(u8),
}
...
pub enum DepthAbsolute {
Default,
Overlay,
Overlay2,
Fixed(f32),
}
Prototype build target
I added a new build target which is configured to compile as quickly as possible to make it easier to test changes to the game.
Structure container and simulation improvements
Belts can’t push into every structure anymore
Belt
s should not be able to fill every building similar to how Arm
s behave.
To achieve that I introduced PlaceType
to track the origin of an Item
.
pub enum PlaceType {
General,
FromBelt,
}
Some of the ItemHandler
methods now provide or use a PlaceType
.
fn try_accept(
&mut self,
module_store: &dyn ModuleStore,
pos_self: &PosRelative,
pos_other: &PosRelative,
x: Item,
pt: PlaceType,
) -> AcceptReject;
fn place(&mut self) -> Option<(PosRelative, Item, PlaceType)>;
Cache interaction pairs
For every simulation tick and every Structure
there were ‘collision’ checks for the Structure
s active interaction functions. E.g. the place
or take
positions of an Arm
. This was pretty expensive to do.
So now those ‘interaction pairs’ are calculated once and then reused for the interaction step of the simulation.
The ‘interaction pairs’ can be cached until a Structure
is added, removed or rotated.