If a part (reader, writer, screen, etc.) doesn't have a cable connected to it, you can't open its GUI. Also, if energy usage is enabled and it doesn't have any energy, you can't open its GUI.

EDIT: These look like they were done intentionally: fc6daae#diff-8c7c896ce904f7d1542f3a7030086262 and ccfcdbb. Why was this decided?

This is indeed intentional.

When the part doesn't have energy, it makes sense that you should not be able to access it. (Note that I have something on my todo-list to notify the user when he/she tries to access an unpowered part)

When it doesn't have a cable, it has no network, so it should not be able to function as well. A similar notification should be given to the user here as well.

I'll leave this issue open to remind myself to implement this soon.

My worry about this, the "no energy" half of it in particular, lies with my new channel system. If you accidentally set a random part to a channel that nothing provides energy on, you won't have an easy way of changing it back, especially if you don't know (or made a typo in) the channel that you set it to. (Or should I just make every part use energy from channel 0?)

Also, how is a part with no cable really any different from a part with a single cable that doesn't connect to anything else?

Hmm, good point, this does indeed complicate things with channels...

The original reason for doing it like this was simply because the implementation at that time made it very difficult to handle parts without a network (i.e. fake cable). Perhaps the latest changes make this easier, not sure.

Feel free to suggest/try changing this behaviour if you think you can improve it.

Or should I just make every part use energy from channel 0?

I wouldn't do this in any case.

Regarding no cable:
I notice that in https://github.com/CyclopsMC/IntegratedDynamics/blob/master-1.12/src/main/java/org/cyclops/integrateddynamics/core/helper/CableHelpers.java#L249, we eject anything inside of a writer when it loses its cable. If I remove the check added in ccfcdbb and put them back in manually, they end up with a green ✔, but the part's status box says "NETWORK CORRUPTED!" Probably not too hard to deal with, and it would make two things slightly easier:

1. Using a reader just to look at its values in the GUI, rather than to set as variables.
2. Using a writer only with a variable card that has a constant or materialized value.

Neither of these are a big deal, though, so I don't have strong feelings about this.

Regarding no energy:
I personally think we should just let the GUI be opened in this case. It's not like you can actually get anything done with the machine even with it. We just need to make it obvious in the readers that the values being displayed aren't accurate (or maybe even hide them altogether).

It definitely makes sense to do it like this. If you're up for it, I can assign this issue to you. If not, I can try to look into it in the not-so-near future.

Go ahead and assign it to me for now. If I get stuck, I'll let you know.