I can second that we are getting this problem on the Brierie server too. But we also have a problem with loading entities in shipyards (as detailed in T2408)

I can say Ive experienced this

Here's the shipyard attached. If for whatever reason you cannot replicate it in a multiplayer enviroment, I assure you just about any shipyard on the Starmade Australia server has these issues and I can provide video footage if need be.

Possibly more information about the origin of the malfunctioned state:
T2408: Shipyard only partially loading entities, then hanging

Open for testing.

@Manithro
As this seems to be a specific problem, and not a general one,
may you please provide us a blueprint of the shipyard so we can test it?

This looks more like a bug-report than a support ticket.

On more testing it looks more like editing a ship is what changes the tracking. The first time I put a missile computer down the missile seems to track but if I delete it and re-place it it won't track properly so width doesn't seem to be a factor.

As above, its Upload from Local to Multiplayer.
Also wish we can search in that menu than have to scroll a very long drop-down list...

Nothing to add.

Might be a few AMD drivers not working properly here, did you try to upgrade or downgrade your driver?

Thank you. I might have an old laptop with an ATI card lying around. Ill check it out

-Validated-

Probably the local blueprint upload list dialog box. Upon pressing that, I get a very long program hang myself, so I generally hit the button and then alt-tab out and do something else :P

-Validated-

Yeah, something's not right with them. Merging task with another one.

They still appear just fine for me in the test sector, could it be something else causing it for you? There was a report about them not working properly when docked to stations or planets, or at least related to docking.

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.

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.

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

I have had this issue when using select target lockon missile turrets

The game hangs for 7-10 seconds when I open the menu, but that is significantly better than crashing outright. Somewhere its fixed itself.

My homing missles do all diverge from the locked target.
In single- and multiplayer. They diverge from the target in perfect curve away from it into empty space.

It was a redundant openal32.dll file in my system32 folder the game tried to call instead of the one in /Starmade/natives/windows/ folder. The redundancy caused everything to go nuts, renaming the redundant OpenAl32.dll solved both the sound and the FPS issue.

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

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.

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.

Just logged back into the multiplayer server and all Rails have lost their links to all Stores on my station, and on all ships docked to my station. So contrary to what I previously witnessed, its not a couple of Rails, its all of them

Thanks for having a look lancake - Id previously thought it was that issue, so I tested it myself (the first time it happened was on a fleet miner carrier), but I couldnt reproduce it like that either.

Adding error log{F17971}

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.

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

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.)

Fixed along the way, closing task.

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).

We're taking some preemptive action tomorrow to clear out the blueprints on the server as we're starting to get instability indicative of the type caused by this bug.

Well, the defaults are:

As is normal, after finally submitting a broad bug report, I was able to track down the freeze to a SINGLE block. There is a rail in the shuttle bay control room (in the top portion of the head) where a single rail somehow became linked to two other rails. I will include a screenshot of the rail with one of the links showing as well as a shot of the logic sitting beneath the rails\buttons. Removing that one rail unfroze all blocks. Oddly, this one rail was linked even on blueprints from before I had a freezing issue. I suspect that the linking was a result of one of the rail updates in the last few months.