Goonhub
07-15-2020, 06:49 PM
This thread is about my recently merged PR https://github.com/goonstation/goonstation/pull/1231
First, an apology:
PR#1231 Had scope creep during development, and was wrongly titled as a "Refactor ..." when it deserved to also have "rework" in the title, and as a github tag. Their omission wasn't intentional, it was just scope creep from the initial purpose of the PR, and me forgetting to update the title and tags.
With that said, I want to outline the reworkings that I did, and why I did them. From there, I'm accepting any feedback and persuasive arguments to revert or modify these changes.
It does not prevent
This change was made because there was a pre-existing TO-DO comment in code file stating that overlapping connections should not be allowed.
So I figured I may as well finish the other coder's to-do, and I took the easiest option: When connecting two devices, if a connection already exists, silently destroy the existing connection, and allow the new one to be formed.
When performing mouse drag-drops, I've never thought to walk mid-drag; In the environment of Wi-fi comps being infinite range, and relays existing at-all, I assumed that MechComp devices had a connection range limit. Thus, when I was first informed, through a private Discord message, that connections could be "walked" infinitely far away, I assumed the behavior to be an exploit. (The user never said it was an exploit, it was just the combined medium of PM, and my never having walked a connection before, that lead to me thinking it was an exploit)
Personally, when I've needed long-range, I've either used wifi, or chained relays. The later method was used in making graviton express-lanes that would turn on LEDs along the lanes when in-use, warning users to get the fuck out of the way.
Since the merge, I've had two players say they don't understand wifi (packets) or that they thought the component itself was broken. If anyone's having trouble with MechComp or other game mechanics I highly encourage them to use MHelp. More specifically, when first learning wifi: I encourage turning forward-all on, and filtering off, to allow for listening and receiving all signals. Additionally: Wifi transmissions don't need do be valid DWAINE packets. you can transmit, and receive anything as a message.
I do think that MechComp connections themselves are somewhat "magic" currently, and that "magic" should have a range limit OR become less-magic. Envision this: what if there was wire(s) representing the connection between each device. Sure, you could absolutely connect a button to a teleporter across the station, but it'd take some layout work. Not even necessarily PNet red-wire, maybe just a simple decal "stretched" from device to device. Until the magicness is reduced, I think a range is appropriate.
From a different but very-much related (And merged) PR: https://github.com/goonstation/goonstation/pull/1405
First, an apology:
PR#1231 Had scope creep during development, and was wrongly titled as a "Refactor ..." when it deserved to also have "rework" in the title, and as a github tag. Their omission wasn't intentional, it was just scope creep from the initial purpose of the PR, and me forgetting to update the title and tags.
With that said, I want to outline the reworkings that I did, and why I did them. From there, I'm accepting any feedback and persuasive arguments to revert or modify these changes.
Quote:Devices can now only have one connection to to each other device: I.E. You cannot connect a single button to each input of a selection component, only a single input.First a clarification: This prevents
Code:
Sensor1 -> Flusher1
Sensor1 -> Flusher1Code:
Sensor1 -> Flusher1
Sensor1 -> Flusher2
Sensor1 -> Flusher3
Sensor2 -> Flusher1
Sensor2 -> Flusher2
Sensor2 -> Flusher3This change was made because there was a pre-existing TO-DO comment in code file stating that overlapping connections should not be allowed.
So I figured I may as well finish the other coder's to-do, and I took the easiest option: When connecting two devices, if a connection already exists, silently destroy the existing connection, and allow the new one to be formed.
Quote:Devices must now be within a range of 14 of each other to be connected. Fixes an exploit of connecting devices far far away.In hindsight, this bullet point wasn't greatly written; here's the context for the change:
When performing mouse drag-drops, I've never thought to walk mid-drag; In the environment of Wi-fi comps being infinite range, and relays existing at-all, I assumed that MechComp devices had a connection range limit. Thus, when I was first informed, through a private Discord message, that connections could be "walked" infinitely far away, I assumed the behavior to be an exploit. (The user never said it was an exploit, it was just the combined medium of PM, and my never having walked a connection before, that lead to me thinking it was an exploit)
Personally, when I've needed long-range, I've either used wifi, or chained relays. The later method was used in making graviton express-lanes that would turn on LEDs along the lanes when in-use, warning users to get the fuck out of the way.
Since the merge, I've had two players say they don't understand wifi (packets) or that they thought the component itself was broken. If anyone's having trouble with MechComp or other game mechanics I highly encourage them to use MHelp. More specifically, when first learning wifi: I encourage turning forward-all on, and filtering off, to allow for listening and receiving all signals. Additionally: Wifi transmissions don't need do be valid DWAINE packets. you can transmit, and receive anything as a message.
I do think that MechComp connections themselves are somewhat "magic" currently, and that "magic" should have a range limit OR become less-magic. Envision this: what if there was wire(s) representing the connection between each device. Sure, you could absolutely connect a button to a teleporter across the station, but it'd take some layout work. Not even necessarily PNet red-wire, maybe just a simple decal "stretched" from device to device. Until the magicness is reduced, I think a range is appropriate.
From a different but very-much related (And merged) PR: https://github.com/goonstation/goonstation/pull/1405
Quote:This will prevent anchored objects from being able to slide tile-to-tile by click-dragging them.This felt like a bug, and I still think this change is deserved. However, if you are a fan of compact setups, look forward to System86's PR: https://github.com/goonstation/goonstation/pull/1257