Open for testing.

Can you still reproduce this?
Played around with this a bit, and could not see any problems.

-validated-

oh great thank you.

In the port cargo bay, where the ventral bay door attaches, the third rail controller down in the stack of four.

Wow, can you add a screenshot or give a coordinate of the problematic rail-speed controller?

To update the case here, the ship has multiple rail controllers, all hooked up to run at different speeds. One of them was not connected to any rails, though it was connected to activation modules. When this rail controller was deleted, the rail lockup issue on the ship was instantly resolved. Disconnecting it from the activation modules, changing their state, etc, had no effect. Only deleting the rail controller block had an impact.

Mirror cubes is definitely not working properly for most blocks but should be unrelated to this issue.
This replace/symmetry part can be seen as a feature request though. In some situations you would want to apply a single orientation replace on a larger area which can be accomplished by using symmetry to extend your build box size. If it also mirrors this you would get undesired results.

One of the older bugs, when a camera is used on a dock, it uses the default orientation (which is the front). Merging with existing task.

Sector export uploaded. I went to the sector to investigate. The ship in question was in the sector, but not at the sector coordinates indicated in the log file.

Asked @Benevolent27 for a sector export.

Found this in the logs:

[2017-02-28 15:59:50] Exiting (normal) because of exception java.lang.NullPointerException: Added nonconform object {RigBExOrig@932909189Ship[LMC Everest III](11244);COLSHAPE:[CubesShape|SER Ship[LMC Everest III](11244)];AT(5072.4854, 755.9233, -986.6366)(SID: Sector[11201](8, 40, 38))}
[2017-02-28 15:59:50] java.lang.NullPointerException: Added nonconform object {RigBExOrig@932909189Ship[LMC Everest III](11244);COLSHAPE:[CubesShape|SER Ship[LMC Everest III](11244)];AT(5072.4854, 755.9233, -986.6366)(SID: Sector[11201](8, 40, 38))}
[2017-02-28 15:59:50] 	at obfuscated.agc.a(SourceFile:108)
[2017-02-28 15:59:50] 	at obfuscated.aPm.a(SourceFile:391)
[2017-02-28 15:59:50] 	at org.schema.game.common.data.world.SimpleTransformableSendableObject.onPhysicsAdd(SourceFile:1907)
[2017-02-28 15:59:50] 	at obfuscated.XR.onPhysicsAdd(SourceFile:2469)
[2017-02-28 15:59:50] 	at obfuscated.aup.a(SourceFile:427)
[2017-02-28 15:59:50] 	at org.schema.game.server.controller.GameServerController.update(SourceFile:1257)
[2017-02-28 15:59:50] 	at org.schema.schine.network.server.ServerController.run(SourceFile:275)
[2017-02-28 15:59:50] 	at java.lang.Thread.run(Thread.java:745)

Still having the issue. This is problematic since the quests on our server require a player to NOT be able to claim the system that their quest instance is created in.

One of the older bugs we have yet I can't find its older task. Maybe not exported from Redmine or I imagined we had that report.
I'll retest this one then.

That is exactly my thought.
Regular clocks do not run in the "logic lag detection" and thus usually do not trigger the "emergency exit" from logic processing because it would affect global server performance.
So yeah, its a side effect of that exploit clock, buffering up signal or signal-changes that cannot be processed that fast.

I have not been able to reproduce this on non-rail clocks as their frequency is far too low for this to happen.

Added information: When I go to open the Structure / Rail Systems key, it takes a long, long time, during which the client freezes. It did this when I played on GenXNova, and it still does it on a local server. Even when all of the entities have been removed from the ship, opening that menu takes a long time.

Waiting for replies/details in Z34.

Screen shot of missing logic

Thank you for sending the server-details.