| commit | author | age | ||
| 987cc5 | 1 | This file is fairly incomplete. Help is welcome. |
| Y | 2 | |
| 3 | Tiers | |
| 4 | ----- | |
| 5 | The tier is a string, currently `"LV"`, `"MV"` and `"HV"` are supported. | |
| 6 | ||
| 7 | Network | |
| 8 | ------- | |
| 9 | The network is the cable with the connected machine nodes. Currently the | |
| 10 | switching station handles the network activity. | |
| 11 | ||
| 12 | Helper functions | |
| 13 | ---------------- | |
| 41f175 | 14 | * `technic.EU_string(num)` |
| H | 15 | * Converts num to a human-readable string (see pretty_num) |
| 16 | and adds the `EU` unit | |
| 17 | * Use this function when showing players energy values | |
| 987cc5 | 18 | * `technic.pretty_num(num)` |
| 41f175 | 19 | * Converts the number `num` to a human-readable string with SI prefixes |
| 987cc5 | 20 | * `technic.swap_node(pos, nodename)` |
| Y | 21 | * Same as `mintest.swap_node` but it only changes the nodename. |
| 22 | * It uses `minetest.get_node` before swapping to ensure the new nodename | |
| 23 | is not the same as the current one. | |
| 24 | * `technic.get_or_load_node(pos)` | |
| 25 | * If the mapblock is loaded, it returns the node at pos, | |
| 26 | else it loads the chunk and returns `nil`. | |
| 27 | * `technic.set_RE_wear(itemstack, item_load, max_charge)` | |
| 28 | * If the `wear_represents` field in the item's nodedef is | |
| 29 | `"technic_RE_charge"`, this function does nothing. | |
| 30 | * `technic.refill_RE_charge(itemstack)` | |
| 31 | * This function fully recharges an RE chargeable item. | |
| 32 | * If `technic.power_tools[itemstack:get_name()]` is `nil` (or `false`), this | |
| 33 | function does nothing, else that value is the maximum charge. | |
| 34 | * The itemstack metadata is changed to contain the charge. | |
| 35 | * `technic.is_tier_cable(nodename, tier)` | |
| 36 | * Tells whether the node `nodename` is the cable of the tier `tier`. | |
| 37 | * `technic.get_cable_tier(nodename)` | |
| 38 | * Returns the tier of the cable `nodename` or `nil`. | |
| 39 | * `technic.trace_node_ray(pos, dir, range)` | |
| 40 | * Returns an iteration function (usable in the for loop) to iterate over the | |
| 41 | node positions along the specified ray. | |
| 42 | * The returned positions will not include the starting position `pos`. | |
| 43 | * `technic.trace_node_ray_fat(pos, dir, range)` | |
| 44 | * Like `technic.trace_node_ray` but includes extra positions near the ray. | |
| 45 | * The node ray functions are used for mining lasers. | |
| 46 | * `technic.config:get(name)` | |
| 47 | * Some configuration function | |
| 48 | * `technic.tube_inject_item(pos, start_pos, velocity, item)` | |
| 49 | * Same as `pipeworks.tube_inject_item` | |
| 50 | ||
| 51 | Registration functions | |
| 52 | ---------------------- | |
| 53 | * `technic.register_power_tool(itemname, max_charge)` | |
| 54 | * Same as `technic.power_tools[itemname] = max_charge` | |
| 55 | * This function makes the craftitem `itemname` chargeable. | |
| 56 | * `technic.register_machine(tier, nodename, machine_type)` | |
| 57 | * Same as `technic.machines[tier][nodename] = machine_type` | |
| 58 | * Currently this is requisite to make technic recognize your node. | |
| 59 | * See also `Machine types` | |
| 60 | * `technic.register_tier(tier)` | |
| 61 | * Same as `technic.machines[tier] = {}` | |
| 62 | * See also `tiers` | |
| 63 | ||
| 64 | ### Specific machines | |
| 65 | * `technic.register_solar_array(data)` | |
| 66 | * data is a table | |
| 67 | ||
| 68 | Used itemdef fields | |
| 69 | ------------------- | |
| 70 | * groups: | |
| 71 | * `technic_<ltier> = 1` ltier is a tier in small letters; this group makes | |
| 72 | the node connect to the cable(s) of the right tier. | |
| 73 | * `technic_machine = 1` Currently used for | |
| 74 | * `connect_sides` | |
| 75 | * In addition to the default use (see lua_api.txt), this tells where the | |
| 76 | machine can be connected. | |
| 77 | # | |
| 78 | # | |
| 79 | * `technic_run(pos, node)` | |
| 80 | * This function is currently used to update the node. | |
| 81 | Modders have to manually change the information about supply etc. in the | |
| 82 | node metadata. | |
| 83 | ||
| 84 | Machine types | |
| 85 | ------------- | |
| 86 | There are currently following types: | |
| 87 | * `technic.receiver = "RE"` e.g. grinder | |
| 88 | * `technic.producer = "PR"` e.g. solar panel | |
| 89 | * `technic.producer_receiver = "PR_RE"` supply converter | |
| 90 | * `technic.battery = "BA"` e.g. LV batbox | |
| 91 | ||
| 92 | Switching Station | |
| 93 | ----------------- | |
| 94 | The switching station is the center of all power distribution on an electric | |
| 95 | network. | |
| 96 | ||
| 97 | The station collects power from sources (PR), distributes it to sinks (RE), | |
| 98 | and uses the excess/shortfall to charge and discharge batteries (BA). | |
| 99 | ||
| 100 | For now, all supply and demand values are expressed in kW. | |
| 101 | ||
| 102 | It works like this: | |
| 103 | All PR,BA,RE nodes are indexed and tagged with the switching station. | |
| 104 | The tagging is a workaround to allow more stations to be built without allowing | |
| 105 | a cheat with duplicating power. | |
| 106 | All the RE nodes are queried for their current EU demand. Those which are off | |
| 107 | would require no or a small standby EU demand, while those which are on would | |
| 108 | require more. | |
| 109 | If the total demand is less than the available power they are all updated with | |
| 110 | the demand number. | |
| 111 | If any surplus exists from the PR nodes the batteries will be charged evenly | |
| 112 | with this. | |
| 113 | If the total demand requires draw on the batteries they will be discharged | |
| 114 | evenly. | |
| 115 | ||
| 116 | If the total demand is more than the available power all RE nodes will be shut | |
| 117 | down. We have a brown-out situation. | |
| 118 | ||
| 119 | Hence for now all the power distribution logic resides in this single node. | |
| 120 | ||
| 121 | ### Node meta usage | |
| 122 | Nodes connected to the network will have one or more of these parameters as meta | |
| 123 | data: | |
| 124 | * `<LV|MV|HV>_EU_supply` : Exists for PR and BA node types. | |
| 125 | This is the EU value supplied by the node. Output | |
| 126 | * `<LV|MV|HV>_EU_demand` : Exists for RE and BA node types. | |
| 127 | This is the EU value the node requires to run. Output | |
| 128 | * `<LV|MV|HV>_EU_input` : Exists for RE and BA node types. | |
| 129 | This is the actual EU value the network can give the node. Input | |
| 130 | ||
| 131 | The reason the LV|MV|HV type is prepended to meta data is because some machine | |
| 132 | could require several supplies to work. | |
| 133 | This way the supplies are separated per network. | |
