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.
