Networked and random portals do not work underwater.

Sign selection for networked portals leads to invalid destination error.
Random portals activate, but do not detect player entry.

Background

A portal without a destination specified is a networked portal. A networked portal with a the r flag is a random portal. A portal with a closing-block specified as water is an underwater portal.

Description.

If a networked (or by extension, random) portal is created underwater, it will not be usable; selecting a destination and activating the portal will appear successful, but the portal will never activate.

Repro steps

1. Make two or three networked and/or random underwater portals, for example,

Test1

TestNet

Test2

TestNet

Test3

TestNet
r

2. Select a destination from one of the portals (not applicable for a random portal), and activate it.
3. The issue will appear.

Summary of Investigation

Thank you to the user @Thorinwasher for this observation:

It would appear that, in this specific circumstance, the activation event is being called twice.

When the activation mechanism (in this case, dead_tube_coral_wall_fan) is used, the gate opens.
When a player enters the portal, it is treated as a separate occurrence of the activation event; ultimately, the gate closes.
When the activation mechanism is used with the gate already being active, the gate closes.

In this case, the activation occurs, the gate opens, then occurs again, and therefore, closes the gate.

This appears to be related to line 935 of stargate.java.

Some testing later, the following determinations have been made:

• The sign properly scrolls through the network
• The network is properly identified, and the list of valid portals is correct
• When selecting (with the dead coral), the correct gate data is sent
• Despite sending the correct gate data, the portal does not activate.
• After selected (with the dead coral), the portal validates itself and resets the sign.

Avenue of investigation will now shift to the activation of the portal itself.

Note that, despite extensive debugging, no differences in console have yet been produced between the working (surface) and dysfunctional (underwater) portals.

Update

Underwater portals appear to be activating twice when they are networked.
Thank you @Thorinwasher for pointing that out.

~ Edited the original post to include a better description of the issue; summarized recent findings.
~ Cleaned up comment thread to only include those findings (by mistake, issue #8 had been merged into this thread).