mt-mods / technic

Technic mod for Minetest

Technic

A mod for minetest

Overview

The technic modpack extends the Minetest game with many new elements, mainly constructable machines and tools. It is a large modpack, and tends to dominate gameplay when it is used. This manual describes how to use the technic modpack, mainly from a player's perspective.

The technic modpack depends on some other modpacks:

• the basic Minetest game
• mesecons, which supports the construction of logic systems based on signaling elements
• pipeworks, which supports the automation of item transport
• moreores, which provides some additional ore types
• basic_materials, which provides some basic craft items

This manual doesn't explain how to use these other modpacks, which have their own manuals:

• Minetest Game Documentation
• Mesecons Documentation
• Pipeworks Documentation
• Moreores Forum Post
• Basic materials Repository

Recipes for constructable items in technic are generally not guessable, and are also not specifically documented here. You should use a craft guide mod to look up the recipes in-game. For the best possible guidance, use the unified_inventory mod, with which technic registers its specialised recipe types.

Documentation

In-game:

• Resources
• Substances
• Processes
• Chests
• Radioactivity
• Electrical power
• Powered machines
• Generators
• Forceload anchor
• Digilines
• Mesecons
• Tools

Mod development:

• Api

subjects missing from this manual:

• frames
• templates

FAQ

1. My technic circuit doesn't work. No power is distributed.
   • A: Make sure you have a switching station connected.

Notes

This is a maintained fork of https://github.com/minetest-mods/technic with various enhancements. Suitable for multiplayer environments.

• Chainsaw and HV Quarry re-implementation (@OgelGames)
• Switching station lag/polyfuse and globalstep execution (@BuckarooBanzay)
• No forceload hacks
• Additional HV machines (@h-v-smacker)
• LV, MV, and HV digiline cables (@S-S-X and @SwissalpS)
• Chests with digilines and more complete user interface
• Most of network code rewritten
• Many bugs that allowed cheating fixed
• CNC machine with pipeworks, upgrades and digiline support
• Better performance
• various others...

Compatibility

This mod is meant as a drop-in replacement for the upstream technic mod.

It also provides some additional machines and items, notably:

• HV Grinder, Furnace, and Compressor
• LV Lamp
• LV, MV, and HV Digiline cables

Note that the wrench mod has been separated from the modpack. It can now be found at mt-mods/wrench.

Recommended mods

Dependencies:

• https://github.com/minetest-mods/mesecons
• https://github.com/minetest-mods/moreores
• https://github.com/mt-mods/pipeworks
• https://github.com/mt-mods/basic_materials

Recommended optional Dependencies:

• https://github.com/minetest-mods/digilines

Recommended mods that build on the technic mod:

• https://github.com/mt-mods/jumpdrive
• https://github.com/OgelGames/powerbanks

Settings (worldpath/technic.conf)

Configuration key	Description
enable_mining_drill
enable_mining_laser
enable_flashlight
enable_wind_mill
enable_corium_griefing
enable_radiation_protection
enable_radiation_throttling	enable lag- and per-second-throttling of radiation damage
enable_entity_radiation_damage
enable_longterm_radiation_damage
enable_nuclear_reactor_digiline_selfdestruct
admin_priv	Privileges required to use administrative chat commands like cache flushing and enabling/disabling machines globally.
quarry_max_depth	max depth of the quarry.
quarry_time_limit	max cpu time in μs allowed per quarry step.
quarry_dig_particles	Enables particle effect with the quarry digs a node.
network_overload_reset_time	After network conflict wait this many seconds before attempting to activate conflicting networks again.
switch_off_delay_seconds	switching station off delay.

See defaults for settings here: technic/config.lua

See configuration for CNC machines here: technic_cnc/README.md

Chat commands

• /technic_flush_switch_cache clears the switching station cache (stops all unloaded switches)
• /powerctrl [on|off] enable/disable technic power distribution globally
• /technic_get_active_networks [minlag] list all active networks with additional network data
• /technic_clear_network_data removes all networks and network nodes from the cache

Contributors

• kpoppel
• Nekogloop
• Nore/Ekdohibs
• ShadowNinja
• VanessaE
• BuckarooBanzay
• OgelGames
• int-ua
• S-S-X
• H-V-Smacker
• groxxda
• SwissalpS
• And many others...

License

Unless otherwise stated, all components of this modpack are licensed under the LGPL, V2 or later. See also the individual mod folders for their secondary/alternate licenses, if any.

technic's Issues

Missing documentation

• Chest sort modes and inventory move buttons.
• Chest digilines functionality.
• Multimeter.

Not sure if anything else is missing...

power monitor "has no network"

@S-S-X looks like your recent commit 7c45e88 has had some impact on the power monitors:

I tried a few constellations but in most of them the monitor has no network.

I see if i have some time to investigate the next few days, no idea yet what the cause would be..

Update/cleanup translations and move to MT 5.0.0+ translation system

It needs to be done at some stage...

• Convert translations to MT 5.0.0+ translation system. - #255
• Add translation to any untranslated strings.
• Fill in any missing translations using a translator (e.g. deepl.com/translator)

Translations for technic are complete as of #289, expect for:

• Multimeter formspec: https://github.com/mt-mods/technic/blob/master/technic/tools/multimeter.lua
• Commands and their chat messages (not sure if this is necessary): https://github.com/mt-mods/technic/blob/master/technic/chatcommands.lua

The other sub-mods still need to have their translations checked and completed.

Allow nuclear reactor core to conduct digiline also directly above and below

Message sending already does this but wont conduct as rules do not allow it.
Update rules to allow messages to pass above and below, this allows using either vertical digilines or vertical digiline hv cable connections.

Here's what should be changed:
https://github.com/mt-mods/technic/blob/master/technic/machines/HV/nuclear_reactor.lua#L433-L438
And there we can use technic.digilines.rules

Remove battery node updates from globalstep technic_run

Remove battery node updates from technic_run and use nodetimers to update batteries.
For actual charge status create single large virtual battery for network so that technic_run can base calculations on single value.

All of following is found from single function, refactor all these loops. Should be able to reduce loops significantly and also even out load to nodetimers:

technic/technic/machines/network.lua

Lines 423 to 445 in f0924df

	for n, pos1 in pairs(BA_nodes) do
	local meta1 = minetest.get_meta(pos1)
	local charge = meta1:get_int("internal_EU_charge")
	local charge_max = meta1:get_int("internal_EU_charge_max")
	BA_charge = BA_charge + charge
	BA_charge_max = BA_charge_max + charge_max
	if (meta1:get_int(eu_demand_str) ~= 0) then
	charge_total = charge_total + charge
	battery_count = battery_count + 1
	end
	end
	local charge_distributed = math.floor(charge_total / battery_count)
	for n, pos1 in pairs(BA_nodes) do
	local meta1 = minetest.get_meta(pos1)
	if (meta1:get_int(eu_demand_str) ~= 0) then
	meta1:set_int("internal_EU_charge", charge_distributed)
	end
	end

technic/technic/machines/network.lua

Lines 464 to 478 in f0924df

	local BA_eu_supply = 0
	for _, pos1 in pairs(BA_nodes) do
	local meta1 = minetest.get_meta(pos1)
	BA_eu_supply = BA_eu_supply + meta1:get_int(eu_supply_str)
	end
	--dprint("Total BA supply:"..BA_eu_supply)
	-- Get all the demand from the BA nodes
	local BA_eu_demand = 0
	for _, pos1 in pairs(BA_nodes) do
	local meta1 = minetest.get_meta(pos1)
	BA_eu_demand = BA_eu_demand + meta1:get_int(eu_demand_str)
	end
	--dprint("Total BA demand:"..BA_eu_demand)

technic/technic/machines/network.lua

Lines 515 to 524 in f0924df

	local charge_factor = 0 -- Assume all batteries fully charged
	if BA_eu_demand > 0 then
	charge_factor = PR_eu_supply / BA_eu_demand
	end
	for n, pos1 in pairs(BA_nodes) do
	local meta1 = minetest.get_meta(pos1)
	local eu_demand = meta1:get_int(eu_demand_str)
	meta1:set_int(eu_input_str, math.floor(eu_demand * charge_factor))
	--dprint("Charging battery:"..math.floor(eu_demand*charge_factor))
	end

technic/technic/machines/network.lua

Lines 541 to 553 in f0924df

	end
	-- We have a deficit, so distribute to the BA nodes
	-- Let's calculate the factor of the supply
	local charge_factor = 0 -- Assume all batteries depleted
	if BA_eu_supply > 0 then
	charge_factor = (PR_eu_supply - RE_eu_demand) / BA_eu_supply
	end
	for n,pos1 in pairs(BA_nodes) do
	local meta1 = minetest.get_meta(pos1)
	local eu_supply = meta1:get_int(eu_supply_str)
	meta1:set_int(eu_input_str, math.floor(eu_supply * charge_factor))
	--dprint("Discharging battery:"..math.floor(eu_supply*charge_factor))
	end

technic/technic/machines/network.lua

Lines 563 to 572 in f0924df

	-- If the PR+BA supply is not enough for the RE demand: Power only the batteries
	local charge_factor = 0 -- Assume all batteries fully charged
	if BA_eu_demand > 0 then
	charge_factor = PR_eu_supply / BA_eu_demand
	end
	for n, pos1 in pairs(BA_nodes) do
	local meta1 = minetest.get_meta(pos1)
	local eu_demand = meta1:get_int(eu_demand_str)
	meta1:set_int(eu_input_str, math.floor(eu_demand * charge_factor))
	end

Do this after #96 is merged.

clear_networks function should be removed

Should be refactored if possible, not checked it that well but it seems that it is overcomplicated and could directly check networks id's where new cable is connecting to and just clear network cache if cable / machine is placed between two separate networks.

A lot of cables.lua code seems to be redundant and also implemented in network caching, there's even comment telling you that.

technic/technic/machines/register/cables.lua

Lines 39 to 118 in c3bed5d

	local function clear_networks(pos)
	local node = minetest.get_node(pos)
	local meta = minetest.get_meta(pos)
	local placed = node.name ~= "air"
	local positions = check_connections(pos)
	if #positions < 1 then return end
	local dead_end = #positions == 1
	for _,connected_pos in pairs(positions) do
	local net = technic.cables[minetest.hash_node_position(connected_pos)]
	if net and technic.networks[net] then
	if dead_end and placed then
	-- Dead end placed, add it to the network
	-- Get the network
	local network_id = technic.cables[minetest.hash_node_position(positions[1])]
	if not network_id then
	-- We're evidently not on a network, nothing to add ourselves to
	return
	end
	local sw_pos = minetest.get_position_from_hash(network_id)
	sw_pos.y = sw_pos.y + 1
	local network = technic.networks[network_id]
	local tier = network.tier
	-- Actually add it to the (cached) network
	-- This is similar to check_node_subp
	technic.cables[minetest.hash_node_position(pos)] = network_id
	pos.visited = 1
	if technic.is_tier_cable(name, tier) then
	table.insert(network.all_nodes,pos)
	elseif technic.machines[tier][node.name] then
	meta:set_string(tier.."_network",minetest.pos_to_string(sw_pos))
	if technic.machines[tier][node.name] == technic.producer then
	table.insert(network.PR_nodes,pos)
	elseif technic.machines[tier][node.name] == technic.receiver then
	table.insert(network.RE_nodes,pos)
	elseif technic.machines[tier][node.name] == technic.producer_receiver then
	table.insert(network.PR_nodes,pos)
	table.insert(network.RE_nodes,pos)
	elseif technic.machines[tier][node.name] == "SPECIAL" and
	(pos.x ~= sw_pos.x or pos.y ~= sw_pos.y or pos.z ~= sw_pos.z) and
	from_below then
	table.insert(network.SP_nodes,pos)
	elseif technic.machines[tier][node.name] == technic.battery then
	table.insert(network.BA_nodes,pos)
	end
	end
	elseif dead_end and not placed then
	-- Dead end removed, remove it from the network
	-- Get the network
	local network_id = technic.cables[minetest.hash_node_position(positions[1])]
	if not network_id then
	-- We're evidently not on a network, nothing to add ourselves to
	return
	end
	local network = technic.networks[network_id]
	-- Search for and remove machine
	technic.cables[minetest.hash_node_position(pos)] = nil
	for tblname,table in pairs(network) do
	if tblname ~= "tier" then
	for machinenum,machine in pairs(table) do
	if machine.x == pos.x
	and machine.y == pos.y
	and machine.z == pos.z then
	table[machinenum] = nil
	end
	end
	end
	end
	else
	-- Not a dead end, so the whole network needs to be recalculated
	for _,v in pairs(technic.networks[net].all_nodes) do
	local pos1 = minetest.hash_node_position(v)
	technic.cables[pos1] = nil
	end
	technic.networks[net] = nil
	end
	end
	end
	end

Cable and machine placement should be simpler than that.

For attaching node to network it should be able to share code used to build network cache.

on_construct and on_destruct

Also very closely related to this, cable on_construct and on_destruct should use different functions, currently it shares clear_networks which makes it look hacky and code is not very clean which also makes it hard to understand and read code.

technic/technic/machines/register/cables.lua

Lines 176 to 177 in c3bed5d

	on_construct = clear_networks,
	on_destruct = clear_networks,

technic/technic/machines/register/cables.lua

Lines 308 to 309 in c3bed5d

	minetest.register_on_placenode(clear_nets_if_machine)
	minetest.register_on_dignode(clear_nets_if_machine)

HV cable digiline support

• check digilines remote mod (performance)

• alternative: lightweight roll-your-own-remote with digiline rules

• New HV cable with digiline field definition (like digimese)

• HV Reactor: proper digiline interface

• Performance testing with huge networks

Iron chest recipe has vanished

enhancing chests

it would be nice to see https://github.com/GreenXenith/technic_chests features added here, sorting, items to and from chest to inv is invaluable for big material moves

Add network inspection tool

Background

I made simple debug hud that displays information for pointed node revealing useful network information, for debugging it has been just network id and location with some supply converter metadata when looking at supply converters.
That was really useful tool during network development as it did reveal problems and also in some case guided finding better ways to handle things.

Proposal

So proposing something similar to network debug hud but as craftable tool so ⚡ everyone can be real power grid engineer ⚡
Tool should give technical internal information about network in game.

Some useful information tool could return:

• network id for node, preferably encoded to be more readable.
• switching station locations.
• network input / output values.
• all_nodes count.
• machine count by type.
• cable count.
• network ttl value, absolute and remaining.
• total battery capacity.
• total battery charge.

Should wait until #96 is done.

Fix machine to power cable connections

Problem:

Network does not care if power cable is actually connected or not by connect_sides rules.

Fix it:

To fix this there should be connection matrix calculated using connect_sides rules and that should be then checked when machine is about to be attached to actual network.

For example, based on this information:

technic/technic/machines/register/generator.lua

Line 126 in c58673f

connect_sides = {"bottom", "back", "left", "right"},

Something like this should be added as rules
(not sure if this follows convention how engine gives directions but similar to this at least):

{
  {x= 0, y=-1, z= 0}, -- Bottom
  {x= 0, y= 0, z= 1}, -- Back
  {x=-1, y= 0, z= 0}, -- Left
  {x= 1, y= 0, z= 0}, -- Right
}

IMO this can be implemented at first by allowing just rotation around y but all possible rotations would be nice, I bet there's tested and working copy/paste code for that somewhere...
However I think that engine also does not always handle rotation correctly with connect_sides so very simple y axle rotation would be fine too.

Where to?

Check should be added here:

technic/technic/machines/network.lua

Lines 199 to 217 in c58673f

	-- Add a machine node to the LV/MV/HV network
	local function add_network_machine(nodes, pos, network_id, all_nodes, multitier)
	local node_id = poshash(pos)
	local net_id_old = cables[node_id]
	if net_id_old == nil or (multitier and net_id_old ~= network_id and all_nodes[node_id] == nil) then
	-- Add machine to network only if it is not already added
	table.insert(nodes, pos)
	-- FIXME: Machines connecting to multiple networks should have way to store multiple network ids
	cables[node_id] = network_id
	all_nodes[node_id] = pos
	return true
	elseif not multitier and net_id_old ~= network_id then
	-- Do not allow running from multiple networks, trigger overload
	overload_network(network_id)
	overload_network(net_id_old)
	local meta = minetest.get_meta(pos)
	meta:set_string("infotext",S("Network Overloaded"))
	end
	end

And possibly also here:

technic/technic/machines/register/cables.lua

Lines 23 to 52 in c58673f

	local function get_neighbors(pos, tiers)
	-- TODO: Move this to network.lua
	local tier_machines = tiers and technic.machines[tiers[1]]
	local is_cable = match_cable_tier_filter(minetest.get_node(pos).name, tiers)
	local network = is_cable and technic.networks[technic.pos2network(pos)]
	local cables = {}
	local machines = {}
	local positions = {
	{x=pos.x+1, y=pos.y, z=pos.z},
	{x=pos.x-1, y=pos.y, z=pos.z},
	{x=pos.x, y=pos.y+1, z=pos.z},
	{x=pos.x, y=pos.y-1, z=pos.z},
	{x=pos.x, y=pos.y, z=pos.z+1},
	{x=pos.x, y=pos.y, z=pos.z-1},
	}
	for _,connected_pos in ipairs(positions) do
	local name = minetest.get_node(connected_pos).name
	if tier_machines and tier_machines[name] then
	table.insert(machines, connected_pos)
	elseif match_cable_tier_filter(name, tiers) then
	local cable_network = technic.networks[technic.pos2network(connected_pos)]
	table.insert(cables,{
	pos = connected_pos,
	network = cable_network,
	})
	if not network then network = cable_network end
	end
	end
	return network, cables, machines
	end

add to contentdb

technic_redo / technic_ng ?

Rewrite all machine/cable registration functions to have generic format

Also see #115 comments.

This would be very good thing for both technic mod itself and for other mods that like to use API functions provided by technic mods.
Currently there's not yet too many mods around using technic API, at least not publicly visible, I was digging large part of internet few months ago looking for these and found just few.
However with good enough API there would be a lot of potential for external mods implementing more machines / cables / something.

Currently API is not that good for external use and could be significantly improved for internal use to reduce code and make parameters and naming uniform.

Currently naming seems to mostly follow some unwritten guidelines so it should be possible to just implement API helpers and remove extra code. Might require renaming some things (textures mostly).

Remove lua api functions marked as deprecated

Clean up ItemStack:get_metadata() / ItemStack:set_metadata(metadata) with serialization stuff around them.
Used with many tools.

Use nodetimers on switching station

Unused textures

As of minetest/minetest@98faeac, mod textures are loaded recursively, which means any textures in subfolders are also loaded.

In the case of technic, the textures in all of these subfolders are unnecessarily loaded (255 textures, 979,092 bytes):

• https://github.com/mt-mods/technic/tree/master/concrete/textures/x32
• https://github.com/mt-mods/technic/tree/master/technic/textures/hires
• https://github.com/mt-mods/technic/tree/master/technic/textures/technicx32
• https://github.com/mt-mods/technic/tree/master/technic_chests/textures/old
• https://github.com/mt-mods/technic/tree/master/technic_chests/textures/x32
• https://github.com/mt-mods/technic/tree/master/technic_worldgen/textures/x32

Either the textures can be removed completely, or they can be moved into subfolders prefixed with "." or "_" (and also excluded from the release export).

Detach regression/unit tests from technic repository

When I first added unit test framework for technic it was just copied from my metatool mod and then extended/modified to allow testing technic network behavior and to allow writing unit tests for network handler functions.

Now I've copied some stuff I've added for technic back to metatool repo and further extended framework there (adding ItemStack, MetaDataRef and few more core libraries)
Some of that stuff is visible here: S-S-X/metatool#61

This framework has been growing to already allow testing a lot of things that utilize minetest core libraries, it might or might contain bugs and does not have tests for itself. Having this thing in multiple repositories is not good for development or reuse.

What would be good way to detach minetest unit test framework from technic repository?
Possible options:

• New repository for framework and pull engine stuff/fixtures as submodule for unit testing.
  Git submodule would allow easier development for testing but has a lot of other not so nice things.
• New repository for framework, build installable packages and distribute those through... something?
  This sounds like better approach and allows building technic mod packages without including all that test stuff.

Opinions / suggestions?

Documentation

There are already some docs in the upstream wiki, but some of the local customizations
should have documentation too:

• HV Reactor digilines
• HV Digilines cable #318
• Polyfuse #318
• Overload (cheat mitigation) #318
• Chest sort modes and inventory move buttons #318
• Chest digilines functionality
• HV Quarry (operating info and digilines functionality)
• Multimeter #318
• Machine registration API #230
• Cable registration API #230
• Chest registration API #232
• Power tool API #233

A simple markdown documentation should suffice

Digiline channels meta bloat

Most machines never get used with digilines, yet they get a channel assigned with their coordinates.
Does anyone ever use this predefined channel in their code?

Wouldn't it be less bloat if a non-unique and short channel was preset?

Like hb, mb, lb for HV, MV and LV battery boxes. Or just plain 'bb' for all tiers.
'ss' for switching stations, 'ff' force fields and so on.

---

"leave it empty (remove generator and just empty) and allow actually using empty channel just like many other digiline devices do."

Above done for battery boxes, do the same for rest:

• Battery box
• Switching station (formspec is good, remove channel generator)
• Power monitor (formspec is good, remove channel generator)
• Nuclear reactor core
  • TBD: Remove "enable digiline" checkbox from formspec and keep digiline always enabled
• Tool workshop
• ?

disable quarry-limit depending on lag

per-user-quarry limit of 10 nodes, should be ok to lift temporarily if the lag allows it

sonic screwdriver does not call "on_rotate"

Unlike the builtin screwdriver mod

Add sounds

Nodes

• technic:switching_station 50Hz humming
• technic:nuclear_reactor_active machine noise
• technic:cnc_active milling sound
• technic:mv_freezer_active fridge sound
• furnaces: ?

Implementation

• ABM/Nodetimers?

setting for "quarry_max_depth"

Allow machines to conduct digiline to all directions

Digiline HV cable was added and it works fine... when you do not connect it to the machines from below.

Machines do not conduct downwards at all but they should if there is digiline cable connected.

Simplest is to just change digiline rules for machines but if digiline connection should be made only for digiline cables then rules should be changed depending on cable connection but only for rules that affect upwards and downward conductivity.

TBD, how machines should conduct digiline messages?
Some possible solutions:

• Any existing and downwards.
• Any existing, downwards and upwards.
• Any existing and dynamic based on attached cables.
• Any existing and custom rules based on machine type.
• Any direction for all machines.

Update network cache building to use execution buckets

Upgrade network building so that it can be used to build caches for any network size and change technic.switch_max_range to be absolute count of network nodes to be checked and added to cache.

After technic.switch_max_range is reached mark network as incomplete and save queues, next globalstep then continues where previous one stopped. Mark network as complete after there's no queue available.

Normal network execution should then begin if network is marked as complete and if not then continue building network.

Multiple switching stations might create challenges here as network building can start at different locations, not sure how to handle this. One way could be to allow only single network build operation and only start new ones after one under construction is completed or disappears.

Also consider possibility to do same for actual network execution for huge and/or laggy networks.

Depends on #96 and should be started only after that PR is merged.

Add particle effects

Nodes

• technic:nuclear_reactor_active blue particles (Cherenkov radiation in water)

Which version of minetest ?

Which version of minetest does this version of the mod work with ? (sorry for my bad english)

Stainless steel ingot looks different in 5.4.0-dev

In Minetest 5.3.0:

In 5.4.0-dev-af22dd86e:

All other ingots (and AFAIK all other textures) look the same.

Remove ABM "Machines: timeout check"

After #96 as that changes a lot around timeout handling.

Use node timer for self contained injector

Don't see any reason why SCI can't use node timer, would also make it easier to add a on/off toggle. Code could also be cleaned up a bit too, particularly the inject_items function...

Combine `concrete` mod into `technic` and `extranodes` mods

Blast-resistant concrete is required by the HV nuclear reactor for it to function, so that should be part of the technic mod, the other various concrete nodes are not used by anything, so they are suitable for the extranodes mod.

Digtron HV power connector not working well or at all

Digtron HV power connector depends on meta value HV_network.
tier .. "_network" metadata keys were removed partially in #80 and completely in #96.

Digtron does not actually use that value for anything but instead simply uses that to check if power connector is connected to valid HV network.

https://github.com/minetest-mods/digtron/blob/843dbd227658a93ee4df791bfdd3d136ee7adf85/util_execute_cycle.lua#L233-L237

for _, power_connector in pairs(layout.power_connectors) do
	if power_connector.meta.fields.HV_network and power_connector.meta.fields.HV_EU_input then
		power_inputs[power_connector.meta.fields.HV_network] = tonumber(power_connector.meta.fields.HV_EU_input)
	end
end

This can be patched within technic mod by adding some compatibility_hacks.lua with following contents:

local digtron_technic_run = minetest.registered_nodes["digtron:power_connector"].technic_run
minetest.override_item("digtron:power_connector",{
        technic_run = function(pos, node)
                local network_id = technic.pos2network(pos)
                local sw_pos = network_id and technic.network2sw_pos(network_id)
                local meta = minetest.get_meta(pos)
                meta:set_string("HV_network", sw_pos and minetest.pos_to_string(sw_pos) or "")
                return digtron_technic_run(pos, node)
        end,
})

Or that check could be removed completely from digtron mod:

   for _, power_connector in pairs(layout.power_connectors) do
-- 	if power_connector.meta.fields.HV_network and power_connector.meta.fields.HV_EU_input then
-- 		power_inputs[power_connector.meta.fields.HV_network] = tonumber(power_connector.meta.fields.HV_EU_input)
++ 	if power_connector.meta.fields.HV_EU_input then
++ 		power_inputs[_] = tonumber(power_connector.meta.fields.HV_EU_input)
  	end
   end

Or tier .. "_network" meta can be restored for machines registered without some network_v2_ready = true flag. probably bad idea...

Or tier .. "_network" meta can be restored for everything. not best solution especially when fact is that digtron does not need or use meta value in question.

switching station gets overloaded too often

Yesterday I built a spaceship with a few cannons and a jumpdrive, and I experienced a lot of issues with switching station overloading, both while building and when using it.

The SS got overloaded almost every time I added something to the network, and also overloaded a few times when I hadn't even touched the network.

Overloading also happened every time I jumped the ship, which was annoying when I was fighting skylord in the warzone. (who also had all the same issues)

By what I've seen (search for "overload" in discord), other players are equally annoyed and confused by the SS overloading, so I'm wondering if there is a way to make it better, or if it should be removed in favor of some other fix for the network bugs/cheats.

• SS got overloaded almost every time I added something to the network
• Overloading also happened every time I jumped the ship
  • see PR #74 comments and mt-mods/jumpdrive#47
  • there's few things that might benefit from creating another ticket for that issue
• what I've seen (search for "overload" in discord), other players are equally annoyed.
  • SX: Every case I checked was actually using cheats...

@S-S-X

Nuclear reactor meltdown crash in vacuum

Steps:

• Build working reactor to vacuum and start it
• Cause meltdown by any means Dig walls and wait until vaporized water causes meltdown
• Crash because group:technic_machine ABM gets called for technic:corium_source

Basically this is what causes ABM call with invalid node:

technic/technic/machines/HV/nuclear_reactor.lua

Lines 213 to 216 in 1113c93

	local function melt_down_reactor(pos)
	minetest.log("action", "A reactor melted down at "..minetest.pos_to_string(pos))
	minetest.set_node(pos, {name = "technic:corium_source"})
	end

Mitigation:
Add check for node name to ABM to make sure node is actually registered technic machine.

There was such test for some time but check was removed because situation should not be possible if ABM would be only called for group:technic_machine.
Check was added here: d7882db
And removed here: 8e0a6ea
Code for that check was not actually never merged to master.

Engine issue: minetest/minetest#8378

Server crash when I try to put a block of the technic mod

Minetest server and client : 5.4
Mods :

• basic_materials (last version)
• pipeworks (last version)
• technics (last version from github)

When I try to put a block of the technic mod, for example the yellow chest or furnace, the server crash with the error below:

2020-11-12 13:20:36: ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod 'technic' in callback item_OnPlace(): Runtime error from mod 'technic' in callback node_on_construct(): .../mods/technic/technic/machines/register/machine_base.lua:184: attempt to index u
2020-11-12 13:20:36: ERROR[Main]: pvalue 'fs_helpers' (a nil value)
2020-11-12 13:20:36: ERROR[Main]: stack traceback:
2020-11-12 13:20:36: ERROR[Main]: 	.../mods/technic/technic/machines/register/machine_base.lua:184: in function 'on_construct'
2020-11-12 13:20:36: ERROR[Main]: 	...bin/../mods/technic/technic/machines/register/cables.lua:348: in function <...bin/../mods/technic/technic/machines/register/cables.lua:348>
2020-11-12 13:20:36: ERROR[Main]: 	[C]: in function 'add_node'
2020-11-12 13:20:36: ERROR[Main]: 	...games/minetest/minetest_5.4/bin/../builtin/game/item.lua:368: in function <...games/minetest/minetest_5.4/bin/../builtin/game/item.lua:258>
2020-11-12 13:20:36: ERROR[Main]: stack traceback:
2020-11-12 13:20:36: ERROR[Main]: 	[C]: in function 'add_node'
2020-11-12 13:20:36: ERROR[Main]: 	...games/minetest/minetest_5.4/bin/../builtin/game/item.lua:368: in function <...games/minetest/minetest_5.4/bin/../builtin/game/item.lua:258>

.luacheckrc contains unnecessary ignores

Many of ignored linter checks should fail and not get ignored.

Failing things should be checked in code not by disabling checks.
Some ignores are of course fine but most ignores that target specific source files in current .luacheckrc are not fine at all, currently there's things that can allow a lot of crash causing simple mistakes to slip through.

Remove these ignores and only add back ones really needed (almost sure that none of these are really needed) and issue cannot be fixed:

technic/.luacheckrc

Lines 32 to 47 in 264029a

	files["concrete/init.lua"].ignore = { "steel_ingot" }
	files["technic/machines/MV/tool_workshop.lua"].ignore = { "pos" }
	files["technic/machines/other/frames.lua"].ignore = { "item_texture", "item_type", "adj", "connected", "" }
	files["technic/machines/register/battery_box.lua"].ignore = { "pos", "tube_upgrade" }
	files["technic/machines/register/cables.lua"].ignore = { "name", "from_below", "p" }
	files["technic/machines/register/common.lua"].ignore = { "result" }
	files["technic/machines/register/generator.lua"].ignore = { "node" }
	files["technic/machines/switching_station.lua"].ignore = { "pos1", "tier", "poshash" }
	files["technic/radiation.lua"].ignore = { "LAVA_VISC" }
	files["technic/tools/chainsaw.lua"].ignore = { "pos" }
	files["technic/tools/mining_drill.lua"].ignore = { "mode" }
	files["technic_chests/register.lua"].ignore = { "fs_helpers", "name", "locked_after_place" }
	files["technic_cnc/cnc.lua"].ignore = { "multiplier" }
	files["wrench/init.lua"].ignore = { "name", "stack" }

Also before adding any of those or like those always consider adding specific ignore rule through source code comments, that way it is at least visible when code is modified.
https://luacheck.readthedocs.io/en/stable/inline.html

Supply converters can not be disabled via formspec

minetest/minetest#10180 triggers the following bug for supply converters:

• If the user disables a supply converter via the formspec, the enabled value is set to 0, effectively clearing the value.
• During the next run step, the "backwards compatibility" code in

  technic/technic/machines/supply_converter.lua

  Lines 132 to 138 in 6a9cf6d

  	if enabled == "" then
  	-- Backwards compatibility
  	minetest.registered_nodes["technic:supply_converter"].on_construct(pos)
  	enabled = true
  	else
  	enabled = enabled == "1"
  	end

  runs the on_construct function, which in turn resets enabled to 1.

This will be fixed by minetest/minetest#10183 . In the meantime, the bug could be resolved by replacing the backward compatibility code with

local enabled       = meta:get_int("enabled") == 1

testing of chinese locales

PR #78 introduced the zh_CN locale and some files are still in the big5 encoding:

• concrete/locale/zh_CN.txt
• extranodes/locale/zh_CN.txt
• technic_chests/locale/zh_CN.txt
• technic_cnc/locale/zh_CN.txt
• technic_worldgen/locale/zh_CN.txt
• wrench/locale/zh_CN.txt

TODO

• Test the translations with a zh_CN locale and check if a utf8 conversion is needed

forceload anchors can't be disabled

neither via formspec nor via mesecons signal

rewrite quarry digging

https://github.com/pandorabox-io/technic/blob/pandorabox/technic/machines/HV/quarry.lua#L184

one node per second should not be that CPU-intensive... 😖

• radical change, may interfere with #15 and make it merge-incompatible

direction of the mod (fork / standalone)

• how to handle upstream updates (if any)

Radiation damage(reopening issue #29)

Hi, I finally spend some time for careful testing of rad dmg. There is imo problem with calling function 'throttle' from 'technic\technic\util\throttle.lua' during registering abm for dmg with label 'Radiation damage'(action = throttle(100, dmg_abm)). With this function rad dmg don't work. Minetest-mods\technic mod use there 'action = dmg_abm', this working. For softening damage is imo using 'chance' enough.
Default settings of max_lag to 1.5 in function dmg_abm is imo too low.

Check and enable metadata cleanup LBM

PR #96 introduced LBM for metadata cleanup but left it completely disabled:

technic/technic/machines/network.lua

Lines 605 to 636 in c89d0a1

	--
	-- Metadata cleanup LBM, removes old metadata values from nodes
	--
	--luacheck: ignore 511
	if false then
	minetest.register_lbm({
	name = "technic:metadata-cleanup",
	nodenames = {
	"group:technic_machine",
	"group:technic_all_tiers",
	"technic:switching_station",
	"technic:power_monitor",
	},
	action = function(pos, node)
	-- Delete all listed metadata key/value pairs from technic machines
	local keys = {
	"LV_EU_timeout", "MV_EU_timeout", "HV_EU_timeout",
	"LV_network", "MV_network", "HV_network",
	"active_pos", "supply", "demand",
	"battery_count", "battery_charge", "battery_charge_max",
	}
	local meta = minetest.get_meta(pos)
	for _,key in ipairs(keys) do
	-- Value of `""` will delete the key.
	meta:set_string(key, "")
	end
	if node.name == "technic:switching_station" then
	meta:set_string("active", "")
	end
	end,
	})
	end

This issue left here as reminder that such thing is available but cleanup is disabled, probably needs to be checked if it does remove all extra metadata that it should remove.
Also I think there's still many properties that should not be in node metadata but still gets stored into node metadata, could be good to collect all metadata setters and determine what is actually needed and what values could live in memory tables as well.

#106 and #108 might affect this too.

switching station delayed switch-off

Tasks

• run switching stations in a globalstep
• switching-station "pool" with last-visited time
• switching station abm refreshes last-visited time
• configurable delay
• metrics

Use-case

• non-afk mining and production
• better reliable machines

Technical guide to release management

I just added release https://github.com/mt-mods/technic/releases/tag/1.1.0

There should be some kind of release cycle guidelines but not necessarily complete feature freezes for next month etc.

It was not too easy to find what was actually changed and if all of it is still backward compatible, here's things that was changed between 1.0 (first) and 1.1 (just created that) https://github.com/mt-mods/technic/compare/4522961..master

So what would be good way to handle releases without affecting rapid development too much?

One way could be through adding tags when it feels like stable enough and low probability for big pull requests in next 7 days or something like that, again I don't think having too specific requirements is good but would be good to have some guidelines.

Okay you've added tag few days ago because you did feel that mod seems to be in pretty good shape, that was probably also tested in some servers for few days. If there was no problems, all tests are passing and tag has been there for few days at least then go hit "create release" button.

Suggestions?

Quarry can sometimes dig above or below limits

From in-game chat:

2020/09/27

SwissalpS: hey, quarry is digging deeper than 100!
chi: it it after a jump?
SwissalpS: no
chi: i heard of some cases of digging ridiculously above or below the machine
SwissalpS: it's really strange. I had put only a couple of nodes thick blob under quarry
SwissalpS: and it dug 101 m under them away
SwissalpS: well almost, it left some little shelves
SwissalpS: I restarted them again and now it's clearing out those remains
SwissalpS: digging at -121 now :p
SwissalpS: oh, one is digging at -195 now :p
SX: have any strange stuff around it?
SwissalpS: well, I recently added digiline control
SwissalpS: otherwise same as since months ago
SX: from code I see only one clear way how this could happen: if dig_index : 0 and dig_index < dig_steps then if it gets somehow stuck into digging partial layers
chi: still leaves things here to
SX: so it never properly finishes layer but moves to next layer without finishing previous
SX: while it is digging layer it does not check depth at all, only when switching layers
SwissalpS: well, on this last run it was all air. only after 100m there was something to dig

2020/12/22

SwissalpS: whoa, this quarry says: digging 7766m above machine
Ruggila: did you jump while the quarry was on?
SwissalpS: no, I have not jumped this ship in over five months
SwissalpS: haven't dug anything with it either
SwissalpS: when I last left it, all quarries had finished
SwissalpS: seems some lbm got it confused. -7766 is the altitude where the quarries are. two of them had this value
SwissalpS: others just said they were digging at normal values. still, I expected all to say: digging finished
SX: dig level is stored in metadata and get_int returns 0 if not set. that might be reason
SX: if dig level is absolute y
SX: using just get can be used to verify as it returns nil for keys that have no value

quarry mesecons control

Cherry picks from hume2's repo

• Forcefield shapes and perf improvements: https://gitlab.com/h2mm/technic/-/commit/b416407c2d14ed3cfef92084b375f6653e6b140a
• 6 Output slots on machines: https://gitlab.com/h2mm/technic/-/commit/38787f9aa307ad5c029e89bc40419c752e4cff72
• network stuff (should be already in here): https://gitlab.com/h2mm/technic/-/commit/2cd2093b337250de8f8ece1bbebe1dbd78f95e5d
• drawers digging (https://gitlab.com/h2mm/technic/-/merge_requests/37/diffs)

LV and MV digiline cables

v1

What do you guys think about these possible textures for LV and MV digiline cables?

I originally was going for just a horizontal blue stripe. It looked good for the wield image but I was sceptical it would work for placed cables. So I went with the stripes with highlight on only one side.

Radiation damage don't work?

Hi, If I use this fork, radiation damage don't work(on pandorabox don't work too).