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. |