To ensure that only rubber tree trunk nodes that are part of trees
regenerate, rather than those that are used as building blocks, check
that they are sufficiently close to rubber tree leaves. This replaces the
older rule that naturally-grown trunks regenerate (regardless of leaves)
and manually-placed trunks don't (even though manually building a tree
otherwise works). The detection of manually-placed trunks was in any
case broken for users of moretrees, because that mod fails to set the
flag signalling manual placement.
Incidentally also fix a bug that caused rubber tree branches (horizontal
trunk nodes) to turn vertical when regenerating latex. Rather than set
the complete node structure, only switch the type name, as does the tree
tap when emptying the node.
With breaking an active reactor core now causing instant meltdown, having
it breakable by hand is too hazardous. Change it to match steel block,
which constitutes the main part of the rest of the reactor structure.
Make the injector's mode button lag-resistant. Display the mode on
the button, as is done with other machines' toggle buttons. Describe
the modes using the same words that are now used to distinguish the
corresponding pipeworks objects. Expand name to "self-contained
injector", now that the pipeworks objects are also called "injector".
Show injector item image along with the item name at the head of the form.
Taking the same time per alloying cycle as other alloys meant that carbon
steel was being produced painfully slowly, becuase it processes much less
material per cycle than other alloys. This change halves the cycle time,
which leaves it still processing less material per second than other
alloying processes, but by a less drastic margin.
Replacing the extractor-based system, uranium to be used as reactor fuel
must now be enriched in stages using the centrifuge. Uranium metal can
exist at 36 levels of fissile content, from 0.0% to 3.5% in steps of 0.1%.
One round of centrifuging splits two dust of a particular grade in to one
dust each of the two neighbouring grades. Uranium of each grade can exist
as dust, ingot, and block, with all the regular metal processes to convert
between them. Uranium from ore exists in lump form, and is 0.7% fissle.
The blocks are radioactive to a degree dependent on fissile content.
Thus the chemical refinement and processing of uranium now follows the
standard pattern for metals, and is orthogonal to isotopic enrichment.
Each form of uranium (dust, ingot, block) intentionally looks identical
regardless of fissile grade.
If technic_worldgen is used alone, it defines only one grade of uranium
(as before), but defines it in the regular metal pattern, with lump, ingot
produced by cooking lump, and block crafted from ingots. It identifies
the metal only as "uranium". The multiple grades of uranium are defined
by the technic mod, which identifies each grade as "N.N%-fissile
uranium". The single grade that was registered by technic_worldgen
is redefined to be described specifically as "0.7%-fissile uranium".
For the redefinition to work, technic_worldgen must load before technic,
so technic now declares a dependency on technic_worldgen.
Each fuel rod is made from five 3.5%-fissile ingots, each of which in
turn requires one to start with five 0.7%-fissile dust, so each fuel rod
is now derived from 12.5 uranium lumps (or 25 if the lumps were first
cooked rather than being ground). This replaces the 20 lumps required
by the former recipes. After setting up and priming the centrifuge
cascade, enriching a full set of fuel for the reactor (six fuel rods)
takes 14700 centrifuge operations. It's intended to be a practical
necessity to automate the centrifuge. In the absence of EU upgrades
for the centrifuges, these operations consume 5.88e8 EU, about 0.97%
of the 6.048e10 EU that the fuel set will produce in the reactor.
The intent is that, in this respect as in others, operating a reactor
should carry a very high up-front cost, but ultimately be very profitable.
There was a small amount of dependency of technic_worldgen on the
technic mod, for configuration loading and the top-level "technic" table.
Resolve that by sharing the configuration and top-level table between the
two mods. This means that technic_worldgen can be loaded before technic,
permitting other mods to depend on it without depending on technic.
The centrifuge, currently only existing in an MV variety, is a machine
that separates a mixed substance into its constituents. Currently the
main use is to reverse alloying of metals. The alloy separation recipes
intentionally only operate on the dust form of metals, making this less
convenient than the original alloying. It also only recovers metal
constituents, not the carbon that went into cast iron or carbon steel.
This change incidentally generalises the technic recipe and
machine infrastructure to handle recipes with multiple outputs.
As unified_inventory's craft guide can't yet handle that, these recipes
are not registered there.
As the layers of reactor structure now have a practical purpose,
in attenuating the modelled radiation from the core, it is no longer
necessary to make so much of it mandatory in order to motivate players
to build it.
The siren sounds a "danger" tone continuously while it is active and
damaged, such that meltdown is imminent. It sounds a one-off "clear"
tone if it has been sounding "danger" and the danger has passed, either
because the structure is repaired or because the reactor has become idle.
The meltdown check now doesn't trigger meltdown immediately on reactor
structure being compromised. Instead, there's a grace period of up to
100 s, during which the reactor can be repaired. The check doesn't just
look at whether the structure is damaged at all: it looks at how damaged
it is, counting the number of faulty nodes. The amount of damage is
integrated over time, and the grace period is actually 100 node-seconds,
so greater damage causes meltdown more quickly. If the active core is
dug then it melts down immediately, preventing the tactic of digging
the core to avert meltdown.
Incidentally move the meltdown check into its own ABM, from the
technic_run callback, so that it applies even when the reactor is not
connected to a switching station.
Radiation is attenuated exponentially by passing through shielding
material. Radiation resistance values are assigned to all bulk-material
nodes, and the radiation damage ABM traces the path of each radiation ray
to count up the shielding. The relative radiation resistance values are
essentially real, but the effectiveness of all shielding is scaled down
by a factor of about 70 for game purposes. Strength of the existing
radiation sources is increased by varying amounts to compensate for
shielding. Uranium block and ore, both usable as shielding, are made
slightly radioactive, the latter only very slightly.
For use on servers that have a mainly creative purpose, the setting
enable_corium_griefing=false will prevent corium from flowing far or
unpredictably and from destroying nodes other than water. All reactor
meltdowns will stay contained.
Reactor `explosion' now replaces the reactor core with a corium source
node. Corium is a new liquid, which flows a bit like lava, but has
the additional feature of destroying nodes to which it is adjacent.
It also randomly turns into a solid form, chernobylite, which makes an
attractive building block. It thus gradually melts its way through the
reactor shielding layers; a meltdown gets worse over time if not cleaned
up promptly.
The mechanism for an active reactor core to damage nearby players is
generalised into a "radioactive" node group. Corium and chernobylite
are radioactive, to varying degrees. Players receive a varying amount of
damage from a radioactive node, depending on proximity. Staying outside
a reactor cube is sufficient to be safe from the active core, but not
sufficient to be safe from a melted core.
Make the use of cans more like the digging and placement of ordinary
nodes, and specifically make it much closer to the use of buckets.
The main change is that left-click with a can is now only used to take
liquid; placing liquid is now done with a right-click. This makes the use
of cans a lot less error-prone, compared to the old scheme of determining
the operation based on the type of node pointed to. Other changes are
that liquid placement is now permitted to replace any buildable_to node,
and the cans obey node protection.
Factor out the logic common to water and lava cans. Provide it in the
form of a technic.register_can() function, which can be called by other
mods to register cans for other liquids.
Drop support for negative mesecon control. This requires users of
negative mesecon control to invert their mesecon signal externally.
Comment on rationale for the way toggle buttons in formspec are managed.
The code formerly attempted to make the forcefield emitter controlled
both manually and by (inverted) mesecon signal, but the two interfered
with each other. In particular, a newly-placed emitted would be
informed that it was getting no mesecon signal, and would therefore
enable itself. Fix this by adding explicit modes for how the emitter
will respond to mesecon signals: ignore them, obey them positively,
or obey them negatively.
The manual control could have been incorporated into this mode setting
by having two "ignore mesecon" modes: always-enabled and always-disabled.
But it seems more useful to have a separate manual master switch, so that
the emitter can be manually disabled without losing the mesecon mode.
So it is now implemented that way.
The low capacity of the prospector turned out to be annoying, while the
other limitations do not substantially detract from fun. Also adjust
recipe to include a blue energy crystal, to explain the source of the
charge capacity.
Use silver instead of gold in the recipe for the red energy crystal,
and mithril instead of gold in the recipe for the blue energy crystal.
This provides more appreciable steps in the expense of the upgrades,
which were too similar, and in particular makes the blue energy crystal
less ridiculously cheap.
LV cables are now paper-insulated, rather than uninsulated (which made
no sense). MV cables are rubber-insulated as before. HV cables are now
plastic-insulated (which they already visually appeared to be). MV and
HV cables are still crafted by adding insulation onto lower-tier cable,
rather than by insulating raw copper; this matches the way machines are
upgraded between tiers rather than crafted afresh.
All electric machine recipes now include cable of the appropriate tier
as the bottom-middle ingredient, immediately below the casing ingredient.
Many LV machines were using a copper ingot in that location.
The casing is intended to be an ingredient in craft recipes for machines.
It isn't actually used in any recipes yet. Although mainly a craft
item, it is defined as a node type, mainly to get an appropriately cubic
inventory image. It is incidentally possible to place it as a node:
this makes some sense, although the empty machine casing isn't actually
useful as a node.
The new tool will say whether a target block type is present in a
specified region, to allow for more targeted digging. It is deliberately
quite weak, with several limitations: only stores enough charge for a
small number of shots; target can only be set by pointing at an example
node; range is limited; accuracy is less than 100%. Some of these
limitations should probably be ameliorated, but not entirely eliminated,
in the future when we have a better idea of game balance.
The inventory image is only a placeholder.
Commit ee0765804c0a21deeb2f33c22ac1a36cb0db5f43 broke the fuel-fired alloy
furnace, by removing the definition of its formspec that it requires to
set up the form upon construction.
A typo in commit d55ecc39f954b33c17ae9a1da4aeff6382fcb790 made recipes
for alloy cooking, compressing, and all other craft types sharing that
machine code, to be shown with three ingredient slots instead of the
correct one or two.
The size configuration is no longer cleared when exiting the dialog with
<esc>. The enable/disable toggle button now indicates the current state.
The name of the toggle button now varies according to state, so that
pressing the button multiple times in one state (which can arise due
to lag making the user unsure about whether the first press registered)
only makes the state change that the user requested, rather than toggling
repeatedly.
A fix for https://github.com/minetest-technic/technic/issues/137
Chainsaw drops are forced to pop above ground. Also, as asl suggested,
they must not end up too high on a ledge or a pillar.
This also cleans up the code style of chainsaw.lua.
If a mining drill is apparently applied to a non-pointable node, do
nothing rather than drilling as normal. This situation usually arises
from lag, where the news of a node having been drilled didn't reach the
user quickly enough and the user thereby applied the drill twice to the
same node. The second drill attempt would formerly consume charge and
then find that all the nodes it wanted to dig had already been removed.
All electrically-powered machines now consistently indicate their
tier (supply voltage) in their names. As this implies that they are
electrically powered, the furnaces no longer have "Electric" in their
names. The fuel-fired equivalents of electric machines, which exist
for alloy furnace and furnace, now say "Fuel-Fired" to distinguish them.
(The fuel-fired alloy furnace used to say "Coal", which was inaccurate
because it uses any fuel. The fuel-fired furnace, from the default mod,
used to just be called "Furnace", which is ambiguous.)
Electric power generators now consistently indicate their tier and have
the word "Generator" in their names. This makes their purpose much
clearer, and makes obvious craft guide searches produce useful results.
The fuel-fired generators, previously just (ambiguously) called
"Generator", are now explicitly "Fuel-Fired".
To support the glooptest mod (successor of gloopores), define the
gloopores lump->dust grinding recipes if either of the mods is available.
(Formerly only "gloopores" was supported.) Define kalite dust item,
which was previously missing. Make gloop ingots grindable to dust as the
non-gloop ingots already are; incidentally refactor this to automatically
make ingots grindable whenever the ingot can be made by cooking dust.
Add textures for all the gloop dusts. Do the "Steel"->"Iron" renaming
for glooptest-defined tools and items.
The size configuration is no longer cleared when exiting the dialog with
<esc>. The enable/disable toggle button now indicates the current state.
The name of the toggle button now varies according to state, so that
pressing the button multiple times in one state (which can arise due
to lag making the user unsure about whether the first press registered)
only makes the state change that the user requested, rather than toggling
repeatedly.
The quarry was digging via dig_node and also manually putting the node's
drops into the tube system. This assumed that dig_node would attempt
to put the drops in the player's inventory, doing nothing if there is
no such inventory. With the item_drop mod installed, dig_node would
instead turn the node into an item entity, so the quarry's strategy would
duplicate the item, making it appear both as an item entity in situ and
as an item in the tube. Instead, the quarry must use remove_node when
it manually processes the drops, just like the pipeworks node breaker.
Override the default mod's iron/steel substance, replacing it with three
metals: wrought iron (pure iron), carbon steel (iron alloyed with a little
carbon), and cast iron (iron alloyed with lots of carbon). Wrought iron
is easiest to refine, then cast iron, and carbon steel the most difficult,
matching the historical progression. Recipes that used default steel are
changed to use one of the three, the choice of alloy for each application
being both somewhat realistic and also matching up with game progression.
The default:steel{_ingot,block} items are identified specifically with
wrought iron. This makes the default refining recipes work appropriately.
Iron-using recipes defined outside technic are thus necessarily
reinterpreted to use wrought iron, which is mostly appropriate.
Some objects are renamed accordingly.
Rather than use the default steel textures for wrought iron, with technic
providing textures for the other two, technic now provides textures for
all three metals. This avoids problems that would occur with texture
packs that provide default_steel_{ingot,block} textures that are not
intended to support this wrought-iron/carbon-steel/cast-iron distinction.
A texture pack can provide a distinct set of three textures specifically
for the situation where this distinction is required.
Incidentally make grinding and alloy cooking recipes work correctly when
ingredients are specified by alias.
Supply the on_refill hook for power tools and cans, to perform appropriate
charging. This is to be used by unified_inventory's creative-mode
refill slot.
The tool workshop is meant to repair mechanical damage to tools, so
is at risk of `repairing' tools that use the wear bar to represent
something other than mechanical wear. It had special-case recognition
of the water and lava cans, which use the wear bar to represent how much
content they're carrying, and wouldn't repair them. But it didn't avoid
`repairing' RE chargeable items, which use the wear bar to represent
how much energy they have stored. It would modify the wear bar without
actually affecting the charge, so the wear bar would jump back to the
correct place when the next charging or discharging event occurred.
To genericise, introduce a new item property, "wear_represents", which
indicates how the wear bar is used for this item. Currently defined
values are "mechanical_wear" (straightforward damage to tools that
start out perfect), "technic_RE_charge" (electrical energy, canonically
represented in the meta rather than the wear bar), and "content_level"
(how full a container is). For backcompat, nil is interpreted as
"mechanical_wear". The tool workshop will only repair "mechanical_wear"
tools. As a bonus, set_RE_wear() will only set the wear bar for
"technic_RE_charge" items: this means developers will notice if they
forget to declare wear_represents, but also means that with no further
changes it's possible to have an RE chargeable item that uses its wear
bar to represent something else.
The injector was in no groups, and therefore not breakable by ordinary
means. This was because the code referred to a defined variable that
went away in the course of a rewrite of the chests code.
These two tools wouldn't discharge all the way to zero through use,
unlike most chargeable items.
Incidentally remove a duplicate of the check_for_flashlight() function.
The flashlight was lighting the wrong node, 1 m east of the player's lower
half, thus getting no light if the player is adjacent to an eastern wall.
Restore the old 1 m above, that coincides with the player's hands.
There was a problem with light from the flashlight getting stuck in
the map. This arises because the flashlight's light value was 15, the
reserved value that the engine uses for sunlight. Moving the flashlight
upwards, by jumping while it is equipped, would cause the node below it to
acquire a bogus sunlit state. Fix this by reducing the flashlight's light
value to 14 (LIGHT_MAX), which is the maximum permitted for non-sunlight.
The light_off node type is not required. With the light value limited
to 14, mere removal of the light node suffices to correctly recalculate
lighting.
The drills weren't taking the variable usage cost into account (either
the per-type base cost or the per-mode multiplier) when deciding whether
they have sufficient charge to use. This could cause them to overshoot in
charge usage, although they would then clamp to zero rather than record
negative charge. Also, for the Mk1 drill where the cost was assessed
correctly, the drill would refuse to discharge to exactly zero charge.
The message to "hold shift" makes an unwarranted assumption about the
user's keybindings. Messages from the server should refer to a key's
game function, rather than its extragame identity.
the first-seen tier for which the machine was registered. So the
switching station, which is uniquely registered for all tiers, would
only visually connect to LV cable when placed, not to MV or HV cable.
(It would function nevertheless, and cable would connect to the switching
station if placed later.) Change to consider all tiers. Incidentally
avoid a gratuitous iteration through all registered machines.
Commit a6dae893d66319739e8dfe962f67285221eb9b91 introduced per-version
charge cost for firing mining lasers, but applies this in addition to
the old fixed cost which it was meant to replace. Fix by removing the
application of the fixed cost.
The same commit did successfully change the check for a laser having
sufficient charge to fire, so that's based purely on the variable cost.
As a consequence, firing a laser that has just enough charge to cover the
variable cost could cause its charge to go negative. (For example, by
fully charging a Mk1 laser and then firing it until it empties, resulting
in a charge of -400.) It turned out that set_RE_wear handled that badly,
producing an over-100% wear value that would wrap to a *low* wear value,
leading to the laser's wear bar looking as if it's fully charged.
To protect against silly wear values, make set_RE_wear clamp the wear
value to avoid wrapping. Handle specially the case of a fully-discharged
tool, where there was desirable wrapping to zero.
Disable the flashlight by default.
Use itemstack:{get,set}_{metadata,name,wear,...} rather than {to,from}_table.
Improve the style of part of the code of mischelaneous tools
The idle condition for mv mashines is changed to what it should be
because sending items into the tube is done in idle, so we only care
if there is something left in src
Theyre already tiered with Mk1-3 (at least drill is, more in the future).
Tools can be considered as designed for different tiers of circuits thx to their power needs.
For example Mk3 will require ages to load in LV batbox.
Batboxes load tools timining: LV standard (1000EU), MV 4x faster (4000EU), HV 16x faster (16000EU)
Also since 1EU is the same in any circuit it is possible to move energy from one to another with portable devices like crystals.
Other changes:
- moved charge/discharge functions to battery_boxes_commons.lua
- added UI style backgrounds for all the batboxes
Still needs some work. I am pushing it to get ideas and feedback.
Also fix some bugs in the LV coal generator that were found while making
the nuclear reactor.
Conflicts:
technic/init.lua
An electrical network now requires a switching station to work. This statin is the one
resolving the network collecting power and distributing it again.
Added up/down converter. It is kind of finished. It can be updated with a slot for an upgrade
but so far it works without by resolving the types of wires above and below the box.
Tool and machine registering changed to use a table with key+value instead of the iterative method it used to have.
The power radiator changed to be able to send up to 3000MV EUs in a radius of 6.
This update will most likely require existing networks to be dug up and placed again. Also the
switching station must be added.
Doing that required some changes to the batteries in that they have new meta data
aligned with the other machines.
I also added a BA type machine in addition to the existing PR and RE types.
This way it is easy to find he batteries on the network.
Added transformers for all voltage tiers.
I changed the recipes for solar panels to make them less expensive.
I also changed the output of the individual panel and made the arrays provie the real "oomph" :-)
Solar panels and arrays are dependent on light level, time of day and height abive ground (0) for output and cheating with torches and stuff.
Textures added.
Fixed bugs in the hv battery box. It was not working at all. I don't understand the hv box top texture though???
I have a sense that all machines connected to the battery boxes are taking the same amount of juice from the box.
A method of taking a little or a lot would be nice.
Now the API is open for adding new nodes and inhibiting some nodes for some materials.
No more recipes outside of the CNC machine.
Code length also greatly reduced.
removed concrete, marble, marble brick, granite, obsidian
stairs/etc from creative inventory, made them work with circular saw in
moreblocks since this mod depends on that one anyway. Removed technic obsidian
block entirely and aliased it to the default obsidian block; all stairs/slabs
for obsidian are under the default: namespace.
This depends on a small fix to the circular saw that was just added by
Sokomine. If your copy of circular saw doesn't have this fix, you can still
use /giveme to get the blocks you need.
Removed custom generate_ore code and made generate-ore calls use
default.generate_ore() since that is the same function anyway. This is so that
technic can use the C++ version of that function when it is moved back into the
engine.
