Changes:
* Make rayIter a global utility, and use it for radiation too.
* prettynum -> pretty_num and cleanup.
* Remove resolve_name/function_exists (unused).
* Cleanup nuclear reactor code.
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.
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.
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.
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.
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.
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.
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.
ShadowNinja
NathanSalapat
RealBadAngel
Vanessa Ezekowitz
MT-Modder
Tim
Wayward1
Novatux
HybridDog
Zefram
Phvli
asl97