Confirmed by Kupu, putting in queue.

In T2385#100190, @Ithirahad wrote:

It is a single activator triggering a large number of forcefield and forcefield wedge blocks distributed across several chunks, likely more than 50000. But this, alone, should not qualify as a 'logic bomb.' It doesn't alternate or repeat automatically to produce a sustained load on the server. Essentially, this 'feature' is just punishing large-scale implementation of the logic system that does not produce a noticeable effect on servers, which I can't imagine is an intended result. (therefore, bug.)

As I'm experiencing it too, then it can happen to other people as well. I do not need confirmation on that, just the questions I asked in my feedback suggestion.
Does width matter here and if off-center weapons cause this behavior to always trigger? From what I've seen it's no, but only the task owner can double check this for sure which is why the issue is set on feedback for confirmation.

Which menu are you talking about specifically?

I'm not entirely sure if it is the normal maps themselves. In your example you have 2 light sources, the one from the star/middle of a system, and your flash light. I did see some weird things when doing your example but it all seemed consistent if I placed my structure at the top of a system, right above a system.
The sides of each of these were very consistent with my flashlight as the star light did not affect it then.

It's only for the block icons, placing the rod lights will give you the correct colour.

Not much to add, blackholes render on top of everything except for the cube edges of the system you're in and text.

You'll get that error if you're trying to build/paste something within the dimension box of another ship/station that is not part of the entity you're pasting on.
We'll make it an optional limitation that is off as default setting.

In T2391#100364, @5ilence wrote:

Awesome lancake, glad you could find the cause here! Note: I incorrectly explained the 'steps to reproduce' in the origainal task, line 4 should read 'C the Rail, and V the storage'. Always get that mixed up haha

Are you still experiencing issues with this? The logs you've posted seem to indicate some problem making the backup to begin with, causing it to constantly retry it for every restart.
Uploading a blueprint to a server should not trigger an entire backup though.

Great, if it's fixed already then this can be closed

Those 5 Trading Guild stations were always invulnerable. The issue where they don't spawn in a response fleet was reported already (T672) but since this system is going to be taken over completely by NPC Factions at some point, it doesn't need fixing.

Not sure why width would matter here, at least it doesn't in my examples. Your 2 meter wide ship has the missile computer in front of the ship core, they're not offset from your aiming reticule so that would be why they always hit the ship core if you're aiming directly at it, tracking or no tracking.

The false positive causing it

java.lang.Exception: WARNING: Irregular block connected to rail speed: (21, 17, 10)[Storage]o[FRONT][active][50hp][BLOCK]; Removing Connection
	at org.schema.game.common.controller.elements.rail.speed.RailSpeedCollectionManager.checkAllConnections(RailSpeedCollectionManager.java:97)
	at org.schema.game.common.controller.elements.rail.speed.RailSpeedElementManager.getRailSpeedForTrack(RailSpeedElementManager.java:53)
	at org.schema.game.common.controller.rails.RailController.handleRailAutoMovementDecision(RailController.java:1196)
	at org.schema.game.common.controller.rails.RailController.update(RailController.java:890)
	at org.schema.game.common.controller.SegmentController.updateLocal(SegmentController.java:2732)
	at org.schema.game.common.controller.SendableSegmentController.updateLocal(SendableSegmentController.java:403)
	at org.schema.game.common.controller.EditableSendableSegmentController.updateLocal(EditableSendableSegmentController.java:1168)
	at org.schema.game.common.controller.Ship.updateLocal(Ship.java:493)
	at org.schema.game.server.controller.GameServerController.update(GameServerController.java:1366)
	at org.schema.schine.network.server.ServerController.run(ServerController.java:275)
	at java.lang.Thread.run(Thread.java:745)

Thank you for the extra information! It seems if a rail is also being used, it will cause some sort of false positive with invalid links and removes them. Not immediately though but after a restart or unloading/loading the client, they should definitely be gone.

Sounds like you're experiencing some form of T2323? In your steps to reproduce you do not mention logic to switch rail connections but I cannot reproduce it with those steps.

Fixed along the way, closing task.

Not a bug but a feature request. Leave a suggestion thread on StarmadeDock

It's something else causing this. The radial menu doesn't catch mouse clicks properly and if you click on anything that leads to another menu such as Structure, Fleet, ... it will also count as a click for anything on your hotbar.
You had your rail docker selected on the hotbar, so while using the radial menu you also used your rail docker causing it to undock.

Duplicate, merging tasks. This bug is only visual, the link is still there but your client won't see it till the next restart (unloading/loading sector might do the trick too).

Yeah for AI it's quite a concern. Easiest solution to this would be to always have power auxiliary on as default when placed down.
I don't immediately see an issue with doing this. If there is one, please leave a comment here explaining why.

Seems to be only affecting clients as the link still works fine (as said in description).
This also applies for logic linked to displays.