AE2 version: rv3-beta-5
Forge version: 10.13.4.1558

Problem

If a P2P tunnel is set from a memory card, there is a hidden flag called output that is set to 1. Saving details from any P2P tunnel with the output set to 1 changes the frequency without notifying the user.

I discovered this problem when I expected to be able to copy the settings of one P2P tunnel I had set up days ago to another P2P tunnel exit. I was completely unaware that I was required to go back to a specific end of the P2P tunnel to copy the settings.

What's worse is that I'm not prevented from turning an input into an output of the same frequency, removing the input from that P2P tunnel forever, with no visual cues as to why it stopped working.

Source

src/main/java/appeng/parts/p2p/PartP2PTunnel.java#L390-L430

That was addressed a while ago.

suggested solution?

Notify the player when a tunnel has been reset due to the use of a memory card.

public boolean onPartShiftActivate( final EntityPlayer player, final Vec3 pos )

…

if( wasOutput || this.getFrequency() == 0 )
{
    newFreq = System.currentTimeMillis();
    mc.notifyUser( player, MemoryCardMessages.TUNNEL_RESET );   
}
else
{
    mc.notifyUser( player, MemoryCardMessages.SETTINGS_SAVED );
}

Where MemoryCardMessages.TUNNEL_RESET is a new message informing the player that a tunnel has been reset to a new frequency and that tunnel face is the input.

More ideally (and additionally), P2P tunnels would have orange around the edges for the input and blue for the outputs (or vice-versa). Blue and orange are typically used as even red-green colourblind players can distinguish them.

Since there's already a convention for coding inputs and outputs, that's great. 👍

wait wait wait, terrible mistake! its blue for input and orange for output as common color coding.

http://feed-the-beast.wikia.com/wiki/Portable_Tank#

but i indeed support the idea of color coding the tunnels in respect to their direction!