To fix it properly, it will need a full rendering queue, to draw everything from "far away to close to the player" in exactly that order.
The engine relies on OpenGL to sort and organise the rendering order,
but it turns out that its not perfect without giving it an exact list for the rendering order.
So once we are feature complete, and know everything we want to render, we can rewrite that part on our own, and help OpenGL doing its job rendering the object we sent to it properly. =)

We released a few improvements on them again,
may you examine the behaviour again?

Open for testing.

Did this happen again afterwards?
It could be some server-side rollback, and not really shipyard related.

Open for testing

Open for testing.

This is a visual artefact only, to allow the client to get back in sync with the server, without having to speedup the rail movement.
As in general a slight speed variance would be easier to notice, we allow the rail to move directly toward the server position.
The server remains in charge of keeping the path checked, so they cannot travel otherwise impossible paths if they would have followed the rails properly, but it gets a few milliseconds back to be back in sync in a short time.

Yeah, that was a mass-comment to usually poke those people again that did not reply on our feedback request, looks like your reply slipped through. (And this was the exact reason we switched toward auto-tagging, so replies do not rely on reading notification mails or looking for them by hand.)

Oh, yes that could indeed be a factor. I tried them vs real enemy factions, not the neutral=enemy setup. Will try them again with this mode.

Tried it again, and it worked properly.

Okay, from the sole building type and construction the turret should work.

Does replicate mean: you could get the bug to happen again and thus upload the logs again, or does it mean you replicated the situation and the bug did not happen?

Thank you for the logs, we will look into them.

In T2094#98298, @Cecil_Effwad wrote:

Could schema please clarify which game build has corrected the problem?
I installed the latest pre-release availabe today and performed the fleet debug mve test described above. At first I thought that the issue was well and truely gone as I watched a fleet of four ships with ten turrets each do a debug mission and keep all their turrets. That worked, so I disabled fleet debug and sent the fleet from one of my bases to another one. When I caught up to them they still had all their turrets. I ordered them home and jumped ahead of them to watch their arrival.
This time they lost all their turrets. Just like before. I turned them back around and followed their flight path until they magically regained their turrets about half-way through the journey.
Was the latest pre-release build the wrong build? Should I install the dev build instead?

According to:
T1678: Uplink does not save
the OSX uplink has been fixed in the Release Candidate.
Will merge this task into the other.

Does this still happen from time to time, or at all again?

Open for testing.

Open for testing.

Open for testing.

Can you please delete the /data/textures directory inside your starmade installation and use the "download normal" option in the launcher screen to restore all textures to default?
(It looks like a broken texture download)

Are you on single player?
Or on a server that may have custom textures?

Nope.
Archived = Mentioned in news, we do not want to mention the issue again.

Yeah, metadata is kept in place, even if the display is removed, kind of another bug, but unrelated to this.

Oh, okay, I understand.
should be enough to test it.