* New MV hydro with upgraded power
The LV hydro is easy to make giving lot of power. The New hydro MV will put a tier system to it; thereby giving more incentive to player to pursue MV hydro plus a little survival aspect. This is a result of [Detailed discussion which is here](https://github.com/minetest-mods/technic/issues/411). Thanks to VanessaE for a good talk and support and enthusiasm to make one :) This will now produce around 175 EU (in between 150-200, so basically average). The MV hydro will give 10x more power than this one. :)
Add the EU_string helper function
In comparison to pretty_num it uses SI prefixes, adds "EU" (e.g. kEU) and rounds the number for readability
Add a constant_digit_count boolean setting
(e.g. if there's room for 50 of some item, and you send a stack of 99,
50 are added to the chest and a stack of 49 is rejected and sent
on to the next destination)
Windmills always span more than one mapblock, so even with a switching station next to the generators, they will stop working if unloaded due to the windmill check failing to handle CONTENT_IGNORE of the frames at the foot of the windmill, unless a second switching station would be placed there.
The commit assumes, that a user has to load a block to modify it, and thus unloaded blocks to have the same windmill frame state as before.
This also makes technic_run for windmills a little faster by being able to skip some unnecessary node lookups and generally avoiding creation of 20 tables per windmill per step.
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.
Tool workshop can now accept tools to repair via tube. It has upgrade
slots. Battery upgrade reduces its power consumption. Tube upgrade
makes it eject fully-repaired (or unrepairable) items via tube.
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.
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.
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".
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.
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.
