From 10221c6c153e4d20bf1d289fe218d29477400a4d Mon Sep 17 00:00:00 2001 From: thetaepsilon-gamedev Date: Sat, 30 Sep 2017 17:32:09 +0100 Subject: add TODO list extracted from new_flow_logic changelog entries --- todo/new_flow_logic.txt | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 todo/new_flow_logic.txt (limited to 'todo/new_flow_logic.txt') diff --git a/todo/new_flow_logic.txt b/todo/new_flow_logic.txt new file mode 100644 index 0000000..acd6d1a --- /dev/null +++ b/todo/new_flow_logic.txt @@ -0,0 +1,6 @@ +-- Per-world configuration of pump thresholds +This should be relatively trivial to do, just a case of adding another property to the pipeworks global that can be set per-world with pipeworks_settings.txt. +This does not appear to be that big a deal right now, as the internal threshold can always be changed. + +-- Internal code to the effect of "is_node_flowable()" +This is basically to implement valves - currently the flow logic will happily balance pipes with neighbour nodes that just happen to have the pressure property in their metadata. -- cgit v1.2.3 From 396a4fdacdd6f80e3bba55cd6c26a2ae321179d1 Mon Sep 17 00:00:00 2001 From: thetaepsilon-gamedev Date: Sun, 1 Oct 2017 18:23:58 +0100 Subject: remove register_local_pipes.lua as node registration has been moved to more appropriate files --- todo/new_flow_logic.txt | 4 ---- 1 file changed, 4 deletions(-) (limited to 'todo/new_flow_logic.txt') diff --git a/todo/new_flow_logic.txt b/todo/new_flow_logic.txt index acd6d1a..46f6c22 100644 --- a/todo/new_flow_logic.txt +++ b/todo/new_flow_logic.txt @@ -1,6 +1,2 @@ --- Per-world configuration of pump thresholds -This should be relatively trivial to do, just a case of adding another property to the pipeworks global that can be set per-world with pipeworks_settings.txt. -This does not appear to be that big a deal right now, as the internal threshold can always be changed. - -- Internal code to the effect of "is_node_flowable()" This is basically to implement valves - currently the flow logic will happily balance pipes with neighbour nodes that just happen to have the pressure property in their metadata. -- cgit v1.2.3 From 57362118dc3a8cfc8eb19997ab54eb307e8e2b44 Mon Sep 17 00:00:00 2001 From: thetaepsilon-gamedev Date: Sat, 7 Oct 2017 13:25:44 +0100 Subject: todo: remove old item for is_node_flowable() --- todo/new_flow_logic.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'todo/new_flow_logic.txt') diff --git a/todo/new_flow_logic.txt b/todo/new_flow_logic.txt index 46f6c22..e69de29 100644 --- a/todo/new_flow_logic.txt +++ b/todo/new_flow_logic.txt @@ -1,2 +0,0 @@ --- Internal code to the effect of "is_node_flowable()" -This is basically to implement valves - currently the flow logic will happily balance pipes with neighbour nodes that just happen to have the pressure property in their metadata. -- cgit v1.2.3 From 157f117c62fafc13994a96bfa5677c40e30ce1b3 Mon Sep 17 00:00:00 2001 From: thetaepsilon-gamedev Date: Sat, 7 Oct 2017 13:40:38 +0100 Subject: todo: new flow logic: add directionality code and ABM ordering items --- todo/new_flow_logic.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'todo/new_flow_logic.txt') diff --git a/todo/new_flow_logic.txt b/todo/new_flow_logic.txt index e69de29..ab7eebd 100644 --- a/todo/new_flow_logic.txt +++ b/todo/new_flow_logic.txt @@ -0,0 +1,11 @@ +-- Directionality code +Currently, only "simple" flowable nodes exist, and they will always equalise pressure with all six neighbours. +A more sophisticated behaviour for this would be flowable node registration with some kind of custom callback, such that water can only flow into or out of these nodes in certain directions. +This would enable devices such as the airtight panels, sensor tubes and valves to have correct flow behaviour. + +-- ABM ordering for event-driven "dropped below threshold" events +For the non-finite liquid mode, cleanup handlers are invoked continuously while pressure is below a certain amount. +This could potentially mean that a below-pressure output node such as a spigot could potentially keep deleting the water source node beneath it, even when one is placed there afterwards by a player say. +Furthermore, attempting to fix this with a "previous pressure" metadata variable is of little use, as the output code is current run in a separate ABM - so the correct sequencing of events cannot be guaranteed. +Therefore, the current code needs revising such that a node's output (or input) handlers are invoked from the main flow logic ABM, in order to ensure correct ordering. +This would also allow the code to compare old and new pressure, and invoke the cleanup handler *only once* if the pressure has dropped from above to below the threshold, and not continuously. -- cgit v1.2.3 From d175f0b94f8164552dc141778f6d832b5faf73a0 Mon Sep 17 00:00:00 2001 From: thetaepsilon-gamedev Date: Sat, 7 Oct 2017 13:49:33 +0100 Subject: todo: new flow logic: add item for node variant switching --- todo/new_flow_logic.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'todo/new_flow_logic.txt') diff --git a/todo/new_flow_logic.txt b/todo/new_flow_logic.txt index ab7eebd..5daa80d 100644 --- a/todo/new_flow_logic.txt +++ b/todo/new_flow_logic.txt @@ -9,3 +9,10 @@ This could potentially mean that a below-pressure output node such as a spigot c Furthermore, attempting to fix this with a "previous pressure" metadata variable is of little use, as the output code is current run in a separate ABM - so the correct sequencing of events cannot be guaranteed. Therefore, the current code needs revising such that a node's output (or input) handlers are invoked from the main flow logic ABM, in order to ensure correct ordering. This would also allow the code to compare old and new pressure, and invoke the cleanup handler *only once* if the pressure has dropped from above to below the threshold, and not continuously. + +-- Automated switching between node variants based on pressure thresholds +When the ABM ordering is complete, an additional callback which would be useful is a "node changer" callback, to switch between variations of a pipe depending on pressure level. +For regular pipes, this is mostly aesthetic, as the empty/loaded variants of the pipes have different texures. +However, the flow sensor is currently a broken device under the new flow logic, as there is nothing to switch this device between the "on" and "off" state - in order to produce a mesecons output, separate nodes are required due to mesecon's API being limited to only on/off for a given node, with no facility for a callback function which could e.g. inspect pressure metadata. +To make this work, a new registry table would be needed to check if a flowable node has this property. +In terms of ordering, this callback should be run after outputs have been processed. -- cgit v1.2.3 From 91d057fcab8bf2caad295148201f1414e935def7 Mon Sep 17 00:00:00 2001 From: thetaepsilon-gamedev Date: Sat, 7 Oct 2017 19:42:49 +0100 Subject: new flow logic: tear out old abm registration code --- todo/new_flow_logic.txt | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) (limited to 'todo/new_flow_logic.txt') diff --git a/todo/new_flow_logic.txt b/todo/new_flow_logic.txt index 5daa80d..3bc8a31 100644 --- a/todo/new_flow_logic.txt +++ b/todo/new_flow_logic.txt @@ -3,15 +3,13 @@ Currently, only "simple" flowable nodes exist, and they will always equalise pre A more sophisticated behaviour for this would be flowable node registration with some kind of custom callback, such that water can only flow into or out of these nodes in certain directions. This would enable devices such as the airtight panels, sensor tubes and valves to have correct flow behaviour. --- ABM ordering for event-driven "dropped below threshold" events -For the non-finite liquid mode, cleanup handlers are invoked continuously while pressure is below a certain amount. -This could potentially mean that a below-pressure output node such as a spigot could potentially keep deleting the water source node beneath it, even when one is placed there afterwards by a player say. -Furthermore, attempting to fix this with a "previous pressure" metadata variable is of little use, as the output code is current run in a separate ABM - so the correct sequencing of events cannot be guaranteed. -Therefore, the current code needs revising such that a node's output (or input) handlers are invoked from the main flow logic ABM, in order to ensure correct ordering. -This would also allow the code to compare old and new pressure, and invoke the cleanup handler *only once* if the pressure has dropped from above to below the threshold, and not continuously. +-- Implement clean-up functionality for output nodes in non-finite mode +register.output() needs to be equipped with an extra "cleanerfn" argument, which is saved into the node's output table entry. +When the pressure level falls below the lower level in non-finite mode, this function would be called by run_output() to e.g. remove a created water source. +Additionally, the outputfn needs to be equipped with a flag to convey the finite mode, so that in non-finite mode the outputfn will drain pressure continuously until the pressure falls below the threshold. -- Automated switching between node variants based on pressure thresholds -When the ABM ordering is complete, an additional callback which would be useful is a "node changer" callback, to switch between variations of a pipe depending on pressure level. +Within flowlogic.run(), an additional hook which would be useful is a "node changer" callback, to switch between variations of a pipe depending on pressure level. For regular pipes, this is mostly aesthetic, as the empty/loaded variants of the pipes have different texures. However, the flow sensor is currently a broken device under the new flow logic, as there is nothing to switch this device between the "on" and "off" state - in order to produce a mesecons output, separate nodes are required due to mesecon's API being limited to only on/off for a given node, with no facility for a callback function which could e.g. inspect pressure metadata. To make this work, a new registry table would be needed to check if a flowable node has this property. -- cgit v1.2.3 From 7e09da50c2896e8a4bcfc6f666d5a63694e682bd Mon Sep 17 00:00:00 2001 From: thetaepsilon-gamedev Date: Sun, 8 Oct 2017 11:41:42 +0100 Subject: todo: update new flow logic items for cleanup handler work --- todo/new_flow_logic.txt | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'todo/new_flow_logic.txt') diff --git a/todo/new_flow_logic.txt b/todo/new_flow_logic.txt index 3bc8a31..2cd15f1 100644 --- a/todo/new_flow_logic.txt +++ b/todo/new_flow_logic.txt @@ -3,10 +3,11 @@ Currently, only "simple" flowable nodes exist, and they will always equalise pre A more sophisticated behaviour for this would be flowable node registration with some kind of custom callback, such that water can only flow into or out of these nodes in certain directions. This would enable devices such as the airtight panels, sensor tubes and valves to have correct flow behaviour. --- Implement clean-up functionality for output nodes in non-finite mode -register.output() needs to be equipped with an extra "cleanerfn" argument, which is saved into the node's output table entry. -When the pressure level falls below the lower level in non-finite mode, this function would be called by run_output() to e.g. remove a created water source. -Additionally, the outputfn needs to be equipped with a flag to convey the finite mode, so that in non-finite mode the outputfn will drain pressure continuously until the pressure falls below the threshold. +-- (may not be possible) stop removing water nodes that were not placed by outputs when off +In non-finite mode, spigots and fountainheads will vanish water sources in their output positions, even if those output nodes did not place them there. +This is annoying though not game-breaking in non-finite mode, where water sources can at least be easily replenished. +Fixing this would require some kind of metadata marker on water nodes placed by spigots and fountains, such that only water sources placed while the device is "on" are removed when it is "off". +It is debateable whether existing water sources should be marked for removal when the device turns on again. -- Automated switching between node variants based on pressure thresholds Within flowlogic.run(), an additional hook which would be useful is a "node changer" callback, to switch between variations of a pipe depending on pressure level. -- cgit v1.2.3 From 085ee7b497489564a0539069ebe781a00d4665e7 Mon Sep 17 00:00:00 2001 From: thetaepsilon-gamedev Date: Sun, 8 Oct 2017 19:13:52 +0100 Subject: todo: remove new flow logic item about node variant switching --- todo/new_flow_logic.txt | 7 ------- 1 file changed, 7 deletions(-) (limited to 'todo/new_flow_logic.txt') diff --git a/todo/new_flow_logic.txt b/todo/new_flow_logic.txt index 2cd15f1..5d83c55 100644 --- a/todo/new_flow_logic.txt +++ b/todo/new_flow_logic.txt @@ -8,10 +8,3 @@ In non-finite mode, spigots and fountainheads will vanish water sources in their This is annoying though not game-breaking in non-finite mode, where water sources can at least be easily replenished. Fixing this would require some kind of metadata marker on water nodes placed by spigots and fountains, such that only water sources placed while the device is "on" are removed when it is "off". It is debateable whether existing water sources should be marked for removal when the device turns on again. - --- Automated switching between node variants based on pressure thresholds -Within flowlogic.run(), an additional hook which would be useful is a "node changer" callback, to switch between variations of a pipe depending on pressure level. -For regular pipes, this is mostly aesthetic, as the empty/loaded variants of the pipes have different texures. -However, the flow sensor is currently a broken device under the new flow logic, as there is nothing to switch this device between the "on" and "off" state - in order to produce a mesecons output, separate nodes are required due to mesecon's API being limited to only on/off for a given node, with no facility for a callback function which could e.g. inspect pressure metadata. -To make this work, a new registry table would be needed to check if a flowable node has this property. -In terms of ordering, this callback should be run after outputs have been processed. -- cgit v1.2.3