- Run all settings through a common API.
- Use modname prefix consistently for setting
keys instead of "nodecore".
- Add automatic dumping of settingtypes.txt
metadata for maintenance.
- Include initial settingtypes.txt for game for
main menu use.
- Remove per-recipe tuning for pummel recipes,
as there were way too many of those to be
possibly useful and it was clogging up the
settings menu. Use tool rate adjustments to
control it instead.
- Remove vestigial enable_damage setting.
The old system effectively cached cross-block
boundary information forever and never expired
them, even if the node creating them was
removed (that would have been easy to fix) or
an obstacle placed in the path (that would have
been difficult to fix with the old method).
Instead just do the simplest thing and split this
into a separate loop, and run a 2-second DNT with
a separate forward-trace from all active optic
nodes.
Doing a second forward trace for each node output
may not be as efficient but ultimately we create more
problems than we solve when we try to be too clever.
Wherever an optic beam strikes a mapblock boundary,
it now creates a particle effect visible to players close
enough. This can be used to plan circuits so they work
entirely within a single mapblock and thus are never
internally interrupted by unloading.
Apparently this interacts badly with
optomechanics when multiple optic
tick cycles are running on a single
globalstep, since it may cause doors to
miss signals if they quiesce back to
off during the step.
Instead of limiting the number of cycles
to some arbitrary upper bound, run as
many cycles as necessary up to a CPU
time limit, i.e. we only allow expansion
of globalstep time by a fixed limit.
If we're running multiple optic ticks in
rapid succession, then we don't return
control to the rest of the game between
ticks, so there's no point in reading the
map more than once per pos, and no
point in updating the map until the end
when optics may have oscillated
across multiple states.
Maintain a cache and commit buffer
during each globalstep and only flush
them at the end.
Apparently as oilboi pointed out, node metadata
is kinda gross, and in this case we didn't actually
need it, since the information could actually
always have been inferred from the nodes
themselves.
Instead of storing output state in node meta,
just register a callback on the node definition to
interrogate the node itself about its power output.
If the server can't handle optics, it would lead to a
runaway effect and bring the system down. Instead
only process up to half a second worth of optics on
each tick, so that this effect is capped and the server
will at least be able to chug along.
Optics keep track of path dependency info
used in calculating state. When a node is
added/removed in the path via the mod API
(i.e. not schematics, vmanip, etc.) then the
nodes whose state decisions depended on
paths going through there are automatically
triggered for a recheck.
This should make things like furnace sand
auto-loaders respond snappily.
Granted, memory use with this approach is
a concern, but we will just have to monitor it
under normal usage patterns.
Optic checks were being propagated unconditionally in loops,
causing nearly every node in an optic network to be checked every
time.
This restores behavior to the original intended behavior of
propagating forward changes on next tick, but stopping at points
where state quiesces.
Unfortunately beam obstruction sensing has been working
instantaneously because of this bug, and that will revert to the
original intended behavior of having those picked up only on
random checks, which may cause regressions in some builds.
- Make lens not flicker with light level dithering by using
histerisis in threshold.
- Optical nodes always read the past world snapshot for creating
the next snapshot, so there are no accidental fast paths
through optical logic leading to glitches (hopefully).
It should now be possible to obtain the new optical stuff given
only resources in-game. The molten glass casting process, in
particular, should be at least a little interesing.
These recipes aren't very interesting and may be subject to
refinements in the future.
There seems to be an issue triggering events, so a lot of work
is being done by the abm to cover over this problem...
Much like my earlier work with sz_rotary, I suspect a lot of
fine-tuning will be needed.
