-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Secure Component Switch (Indepth Explanation Within) #1277
Comments
This'd fix #1273 right? On Wed, 8 Jul 2015 9:26 pm Kodos Atoz notifications@github.com wrote:
|
It's a more advanced version, essentially. I liked the idea, but didn't want just a simple 'hurdur redstone to turn on' cable toggle. I could just about program that in Lua |
Yeah exactly. On Wed, 8 Jul 2015 9:43 pm Kodos Atoz notifications@github.com wrote:
|
@Kodos-Atoz In fact, I did program such a thing in Lua, using a Robot and different dyes to change the cable colour. |
Whys there even a component limit <.< Other than that, interesting idea, don't like the password stuff though, should be done via programs. So that component block has 6 sides. Whichever side is connected to the PC is used for the PC to access it (obviously). With a call of something like setOutput(side) you switch which output side is activated, and it acts like that side is connected to the input side via cable then. (So PC can see everything connected there) |
At the point of where you would put in an extra block for this you could really just change how the system works though... Like the machine.lua component thingy has a table of max size 16, which holds addresses, only the component addresses listed there can be used. So to "connect" a new component you'd have to get its address and add it to the table (but maybe you have to throw out another address for that if it is already full). And so on, that way you can switch components. That way the limit also makes a bit more sense (PC has limited address memory for accessing components), and isn't just pulled from thin air. |
If you hate the limits that much, change them in the config. This is my own version of a sane solution. |
And I prefer a solution that makes the limits make sense, and doesn't add unnecessary blocks :D |
@Inari-Whitebear if you want to discuss component limits, do so in a separate issue. |
@LizzyTrickster I'm not "discussing component limits". Not sure why everyone gets so hung up about that once I mention it once :P One of the purposes of the suggested block is obviously to be able to switch between sets of components. So you can have a total number of components bigger than the currently active components and turn those on/off as you please. So I'm pointing out that the same functionality can be achieved by changing the component API and machine.lua a tiny bit. Instead of implementing a whole new block for the same end-goal. Sure, the 2 things could technically co-exist, but I still don't see a reason to add a new block where it is not needed at all. At the end that is at Sangar's discretion anyway though, I'm just giving my thoughts/feedback. For which issues/suggestions are kind of there too. And I don't think I should open a new issue for that idea, since it is discussing the purpose of this suggested Block and alternative ways to get that functionality. So at least until this feature is accepted, what I'm saying is, that there would be an (imo) better way than what is proposed. That would be like me telling people who don't 100% agree with my idea for quicker drawing to "get out and make your own issue". Doesn't make sense. |
The changes to the limits aren't really needed either. 16 is plenty for a normal user, and if you need anything more than that, you should probably be finding ways to implement what you're doing via a server rack, which can support up to 64 components per server anyway. Please stop derailing the topic. The suggested block is a QoL suggestion more than anything else, but could be useful for securing networks as well. |
Well you didn't want to explain to me what other uses your block has, so I have to go by the issue's description. Past passwording stuff - which can really be done with software - the only use I can see is that you can connect and disconnect subnets. Which as stated (even by you), allows to have a total number of components bigger than the current number of active components. Not sure what exactly you mean by securing networks ^^ Other than to manage power draw better, it sounds like it would mostly be useful for having a bigger set of technically available components. So you are saying, that the block is not necessarily required, but would be a QoL thingy that just makes something a bit more user-friendly? (Off/Meta-topic: I don't regard discussing your suggestion, its merits, and alternatives as derailing a topic about your suggestion?) |
Say you wanted to switch a single screen to display multiple cases? On Thu, 9 Jul 2015 4:25 pm Inari-Whitebear notifications@github.com wrote:
|
Hm, interesting idea. Though it has 1 input and 5 outputs. So only one case could input into the screen? Unless you had like 2 of them, and only 1 was turned on, but then you'd have to communicate between the cases which draws to the screen or something? |
I don't think this is a good idea, but you could have an inverted mode, with 5 inputs and one output. If anyone has any suggestions as to what that would be good for, I'm all ears. |
Well what comes to mind would be what they had at BTM, where they had the presentation running, but Sangar also placed a case to showcase stuff and the main screen could be switched between the 2. But then again, that could be done by using the address memory stuff too |
@Inari-Whitebear That's what I made the program I previously mentioned for. That presentation at BTM. And that's why this is a thing. |
I see one use for such a block: A (hardware) diode-like block (so, one-way-gate). Could still be implemented by having a PC or preferably MCU. But MCU aren't capable of that and PC might be overkill. |
Due to how OC's networking works, one-way access to components isn't really possible, which, as I understand, this suggests? For dynamically switching subnets, there's the toggle cable thinger now. |
Alright, here goes my best attempt to explain this as clearly as I can.
The Secure Component Switch would have one sided 'input', and five sided 'output's. This would enable entire sections of components to be independently added and removed, allowing for everything from being able to have more than the normal limit of components added to a computer (via being able to 'shut off' certain sections of the network), to being able to have things like password protected Raids, etc.
Here is an example screenshot of its usage.
In the above screenshot, let's pretend that the two pieces of wool are both Secure Component Switches (Hereafter referred to as SCS). In the green one, a method has been called to enable a computer attached on the lefthand side to reach the second SCS on the right. However, in the righthand SCS, the method to disable the right-side facing of the SCS thus preventing the computer from accessing any components beyond that point.
Optionally, I'd like to be able to add a 'password' string to the SCS, in the same manner that Zetta Industries does in the RF Meter's methods. If further explanation of that is needed, I can provide links to the ZI Repo, or if @marcin212 would be willing to elaborate he is most welcome to.
If there are any additional questions, drop me a line here or in IRC.
If you've gotten this far, thanks for the time you took to read this, and I hope this is taken into consideration.
The text was updated successfully, but these errors were encountered: