Digiline Filter Injector does not receive digiline signals from vertical sources

[g-whiz]

Digiline signals cannot reach Digiline Filter Injectors via Digiline Conducting Tubes connected to the "To" end of an injector. However, Digiline tubes adjacent to the injectors (i.e. next to one of the sides displaying arrows) do conduct their signals to the injectors. This seems like it may be an issue where injectors are not "connectable" to digilines on their ends, however this cannot be tested with normal digilines.

Digiline Filter Injectors do not receive digiline signals from conductrs above/below the injector. This occurs regardless of how the injector is oriented, and no matter what block is used to conduct the digiline signal.

This makes it impossible to use vertically oriented digiline tubes to carry a signal to a vertically oriented digiline filter injector.

[fluxionary]

basically, if the tube connects, digiline signal is not transmitted; if it doesn't connect, digiline signal is transmitted? i was wrong, ignore this.

[S-S-X]

Injectors use default rules which are:

digilines.rules.default =
{{x=0,  y=0,  z=-1},
{x=1,  y=0,  z=0},
{x=-1, y=0,  z=0},
{x=0,  y=0,  z=1},
{x=1,  y=1,  z=0},
{x=1,  y=-1, z=0},
{x=-1, y=1,  z=0},
{x=-1, y=-1, z=0},
{x=0,  y=1,  z=1},
{x=0,  y=-1, z=1},
{x=0,  y=1,  z=-1},
{x=0,  y=-1, z=-1}}

Which does not include positions directly above or directly below. And remember that matching (connecting) rule must be in both nodes involved in digiline connection, having rule for just one of them isn't enough.

This makes it ignore input and output positions when injector is rotated in a way that output points either upwards or downwards.

IMO there's 2 acceptable solutions and 2 bad solutions:

1. Acceptable (and simple): just add up/down positions to current rule and possibly break few existing setups and make it bit harder to reduce rules in future.
2. Acceptable (better future but bit more complicated): PR to digilines mod that adds position information for dynamic rules, then make rules follow injector rotation and possibly break few existing setups (and while at it just try to PR OgelGames/digicontrol overrides).
3. Bad: require OgelGames/digicontrol overrides and use those to make dynamic rules.
4. Bad: add injector proxy nodes that handle rotation, without LBM or with technic screwdriver it wont necessarily break existing setups but adds both node count and (unnecessary) complexity.
5. use pipeworks.digilines_rules and break a lot of existing setups.
6. fork digilines.

[Desour]

2. **Acceptable (better future but bit more complicated):** PR to digilines mod that adds position information for dynamic rules, then make rules follow injector rotation and possibly break few existing setups (and while at it just try to PR OgelGames/digicontrol overrides).

You don't need the position for the rotation. And there should already be a rule getter function that receives param2.

---

Btw. if this is done, one could consider adding the same rules for mesecons.

---

If you just add the rule to connect forwards (to the output direction of the filter), and rotate it correctly, the only broken builds are those where the filter is vertical and there's a node at the output that sends a signal.

[S-S-X]

You don't need the position for the rotation. And there should already be a rule getter function that receives param2.

Oh you're right and I apparently had brain short circuit, of course param2 already comes with node.

I guess that would be best way to fix it while still allowing 2 sides that wont connect (which at times can be useful, well not theoretically but practically because of other stuff in servers...) and without adding more rules at least not just yet.

[g-whiz]

still allowing 2 sides that wont connect which at times can be useful

For Digiline specifically, is this really all that useful? Given that components are individually addressable, it seems like a design that relies on 2 sides not connecting could simply use channel names to "separate" things instead.

For example: I have a build where I have a lot of machines that don't interact with each other that are all connected to the same master digiline bus. By picking appropriate channel names, nothing interferes with anything else.

Obviously the same does not apply to mesecons connectivity. So I think the digilines distinction ought to be emphasized.

2 acceptable solutions and 2 bad solutions

I can think of one additional solution: make Digiline Filter Injectors conduct digiline signals (the same way that the digiline tubes do currently). This would be a more drastic change, and ultimately is more than a bugfix. I don't think it is acceptable in the context of this issue, but it might be worth raising more broadly (e.g. why not have other digiline-compatible blocks - like Autocrafter - conduct digiline signals?).

[S-S-X]

I can think of one additional solution: make Digiline Filter Injectors conduct digiline signals (the same way that the digiline tubes do currently). This would be a more drastic change, and ultimately is more than a bugfix. I don't think it is acceptable in the context of this issue, but it might be worth raising more broadly (e.g. why not have other digiline-compatible blocks - like Autocrafter - conduct digiline signals?).

Yeah, actually that was 5th in list... as a use pipeworks.digilines_rules and break a lot of existing setups..
edit. actually yes it wasn't exactly that. You're talking about actually conducting which like you said would be a lot bigger thing, and sure deserves its own issue for discussion.
Would be such big change I bet there would be a lot of opinions for, against and everything in between...

But to get back to your previous question

For Digiline specifically, is this really all that useful? Given that components are individually addressable, it seems like a design that relies on 2 sides not connecting could simply use channel names to "separate" things instead.

Why exactly I stated which at times can be useful, well not theoretically but practically because of other stuff in servers... is that while theoretically having everything connected to everything would be ideal it isn't ideal in real world.
On reason is that makes it way harder to connect devices that have heat value, keep them cool and have them all on universal bus.

That's why it is actually useful to isolate networks instead of everything being connected to same network. People like to build in tight space and simultaneously keep things actually working at maximum rate without burning connected devices.

By picking appropriate channel names, nothing interferes with anything else.

Ever tried connect few lua controllers there and then count handled messages and take a look at heat value?

[g-whiz]

Why exactly I stated which at times can be useful, well not theoretically but practically because of other stuff in servers... is that while theoretically having everything connected to everything would be ideal it isn't ideal in real world.
On reason is that makes it way harder to connect devices that have heat value, keep them cool and have them all on universal bus.

Ah, I see. I have a feeling that the number of builds on relevant servers that would break because of this change is minuscule. It is a rather obscure behaviour to begin with, and - assuming proper channel-labeling of devices - breaking a build would require:

1. a vertical digiline conductor on a separate bus to be placed above/below the injector, and
2. the bridging of these two busses to cause one or more heat-valued devices to burn.

Given the combination of these criteria, I wouldn't be surprised if the specific servers where this would have an impact don't have any such builds.

Nonetheless, this edge case could be mitigated by adding a setting (e.g. to default_settings.lua) to allow legacy digiline injector conduction rules to be toggled.

[eshattow]

Related? or no...

[FeXoR-o-Illuria]

This would e.g. break my multi ingredient autocrafter setup and will make it require more nodes with 50% probability depending on the orientation x)

IMO connectivity should be symmetric under rotation so no additional work needs to be done when rotating nodes that connect e.g. to conduct digiline signals (One example where this is done is technic cables but also meseblocks and digimese - for different types of connections/signals).
Adding top and bottom to connect would fulfill this - the other options given so far won't.
(The vertical edges are also not connecting)

If you want to go for 2 or 3 proposed in: #64 (comment)
For vertical digiline injectors:
_ Only half of the vertical faces will connect
_ Only half of the horizontal edges will connect
... both without any visual clue which ones.
Will we also be able to rotate digilines, the default conductor, also with non-symmetric connection rules under rotation, so we can actually make use of the/some vertical edges connecting? Oo

Somewhat related: Insulated mesecons visually communicate clearly (Hm, do they connect through their bottom edges? Top edges? x) which directions they will connect - independent of the surrounding nodes - and where they connect is rotated with the node. That's OK, too, IMO. (I'm not sure how exactly they can be oriented - but that's somewhat a different matter)

This digilines (and mesecons) default connectivity is a mess IMO but allowing rotation would only make it worse.

[Deathwing777]

Digiline Filter Injectors do not receive digiline signals from conductrs above/below the injector. This occurs regardless of how the injector is oriented, and no matter what block is used to conduct the digiline signal.

This makes it impossible to use vertically oriented digiline tubes to carry a signal to a vertically oriented digiline filter injector.

I can confirm that this is not just a digiline filter injector issue, but is also an issue for pipeworks deployers and node breakers as well. Node breakers and deployers that are vertically oriented can no longer receive signals from digiline conducting tube that connect to their tube inputs/outputs. This completely breaks the expected behavior of these devices! If people are seriously concerned about "breaking" existing digilines builds, you could just expose the connection rules to the formspec, and let the user decide. Seriously though, anyone needing isolation between digiline networks should be using digiline diodes/filters/etc to keep local digilines networks separate from larger digiline networks that don't need to know anything about machine scope digiline devices.

In general digiline devices should connect on all sides, and even conduct as was mentioned previously in this thread, to fit with the serial bus metaphor. There are established ways for filtering and limiting the scope of digiline networks while maintaining connection to larger digiline networks.

See: minetest-mods/digilines#37
&
https://content.minetest.net/packages/OgelGames/digicontrol/

For mesecon devices, if this is an issue (haven't tried), working out a way to have the connection rules follow the node rotation seems ideal, and would only involve a simple matrix rotation. Changing the node textures to indicate which faces do not connect would also be a good idea.

[Deathwing777]

To make matters worse, the pipeworks deployers have to deploy seeds vertically into the bottom of a block of farm soil, so this situation makes digiline farming impossible!

[SwissalpS]

this situation makes digiline farming impossible!

Not quite impossible, just not possible to have massive amounts of deployers right next to each other without spaces.
You can make 2*x rows, rings of 8 etc.

Best automatic farming is a line of 11 fields anyway and in my experience having 2 fields is already sufficient to keep a player well fed if they are located at a reasonably frequented location. (Like ore-deposit/sorting)

[Deathwing777]

If I was interested in working around the broken code in-game I would be posting on a forum, not GitHub. It is IMPOSSIBLE to activate vertically oriented node breakers and deployers with digiline conducting tubes! Now that is just embarrassing! With digilines you should be able to build a dense farm where every soil block in an arbitrary NxM area sized farm is actively being actively farmed.

Anyway, the OP was well over a year ago and I don't see any pull requests that fix the issue, so I will do it myself. Thinking about it, this could be fixed with a single "Conductive" boolean variable in the formspec right next to the digiline channel. If left unchecked it would have the same (broken) connection rules. If checked it would connect to digilines on all 6 faces.

[Deathwing777]

Pull request is in. The code is tested and I can verify that it fixes the issue. Once getting into the code, it became clear that rules are applied at a more abstract global level than that of the individual node instance. So my original plan of exposing the option to the node formspec started to look like a much bigger project than I intended. I opted to go with a simple server-wide boolean setting in the default_settings.lua file that get checked prior to setting pipeworks.digilines_rules in common.lua. This leaves it up to the server admins.