Clearing the "asked" flag on undocking should do the trick

-QA Testing-

-QA Testing-

Nvm, wrong task.

-QA Testing-

-QA Testing-

-QA Testing-

-QA Testing-

-QA Testing-

There might still be a special case out there involving shoot out rails, but I can't find anything else anymore...Better to just close it and make a new task for anything new.

@Lunchbox and @The_Onion
Can any of you upload a blueprint of the ship + thing docked to it that causes it? And/or provide very clear steps to reproduce for a simple example?

Tried out that blueprint and works just fine, looking at the logs, it's a NaN issue which received another fix on 11 March 2017, meaning only 0.199.535 has it. The task number is T1422 although it's a private issue so you won't be able to see its content.

Possibly related to the "swiss cheese" issue where some chunks would not load, or not load immediately. Anything having a rail in those chunks would then not be able to dock.
This was addressed before so most likely also fixed any issue that caused this one.

Seems to be working fine now, probably fixed along the way since I remember doing something (or poking someone) about it. Works fine for multiple languages, both in SP and MP.

This bug would have been caused by a Not a Number exception, something that probably can still happen with shoot out rails, although that's a different task.
Rejecting as there wasn't any new feedback or clues on this, assuming it doesn't happen anymore (for normal docks).

They all shoot out diagonally now, at a 45° angle between the direction it is supposed to go, and the direction perpendicular to it. Video made by author shows it clearly too.

Im having the same issue. My setup was a plexdoor box that closed around the entity while it was still on the rail, then a shootout rail to disconnect, and a pickup rail on the receiving entity. It all works as intended, The plexdoor enclosure keeps the entity in place when the shootout rail disconnects it, then after five seconds the pickup rail attaches it the next entity. The problem is that at that point, the object im moving is now stuck. Even breaking the rail docker wont free it, Only after I restart my game will it unfreeze.

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

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

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.

even now I still produce unmovable cores. But only on the server. In a local game there s no problem

That is exactly the problem with it.
Seems to only attack active AIs but also seems to ignore factioned ships without relation.

Have you turned on the target ship's AI? Turrets don't target inactive AI ships regardless of IFF.

Tried ingame, totally true and odd behaviour.

Fighting was about the issues long directory names can cause, if you go beyond sane limits.
Anyway, if the max chain docking setting does not work it would be a different report to look into.

Yes, they are in a single chain one on top of the other.
It appears the server is completely ignoring the setting. It should have stopped me several times from docking then. I say that because you are correct that is in the config file.
MAX_CHAIN_DOCKING = 25 //maximal deepness of docking chains (may cause glitches depending on OS (path and filename length) at high numbers)

I assume those entities are in a single long chain, right?

It still exists just checked in latest versions.
http://i.imgur.com/vXu9N1d.png
The stack you see on the left is what i created in game 128 docked entities.
The right was what came of trying to admin spawn a copy of it. 108
Figured that was faster than building an entire station and entities over again.
The system still thinks there should be docked parts on it and tries to transfer you up to it if you use the arrow keys. This results in a Long pointer null exception error.

Glad to hear that,
thank you for confirming it has already been fixed.

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

Hey there, the bug is still present in 199.535, but it's not logic linked, it's when a drone is docked on the rail which is linked to the storage pulling module (tested it with a drone carrier), the link randomly vanished or totally I haven't found any clues for the reason why that is still occuring.

-QA Testing-

It is possibly fixed with this. But I can't be sure.. The reason this seems OS dependent is because this is a running condition, so it really depends on how fast/slow threads are being handled.

Ok ok, perfect then ^_^good work guys and tanks for all !

Just a quick question on this. I was considering putting in a potentially related bug issue. But it might not be depends on how your resolved this.
The bug I was going to report is if there is a long chain of entities docked such as I had station modules docked to a station with ships docked to that and other ships docked to that one and the turrets and so on.
Apparently that also will end up loosing entities.
It is different based on which OS you are on. It is related to the directory structure and windows only being able to handle certain length paths to files.
I realized the issue when I was making large chained power supplies. I didn't consider the issue how it might effect other stuff. Or there might be a circumstance someone docked that much together.
So that was a bad assumption on my part and I should have reported it then.
Anyway the question is this issue related and does the fix to this fix what I am talking about or does that need a separate report?