Digiline Filter Injector does not receive digiline signals from vertical sources
g-whiz opened this issue · comments
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.
basically, if the tube connects, digiline signal is not transmitted; if it doesn't connect, digiline signal is transmitted? i was wrong, ignore this.
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:
- 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.
- 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).
- Bad: require OgelGames/digicontrol overrides and use those to make dynamic rules.
- 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.
use pipeworks.digilines_rules and break a lot of existing setups.fork digilines.
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.
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.
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?).
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?
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:
- a vertical digiline conductor on a separate bus to be placed above/below the injector, and
- 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.
Related? or no...