It's magic.

-QA Testing-

-QA Testing-

seems to be resolved?

Fixed a while back

It is extra confusing, as cloning the design from an existing blueprint doesn't have this problem. (I do this all the time, as I only rarely deconstruct to design)
(yes, yes, yes, I'm aware you all want to get rid of blueprints, that does not negate the simple fact that cloning the design from a blueprint doesn't have the problem)

The current stacktrace is old and is probably not relevant anymore.
Break off crashes still happen though.

Requires the launcher update to roll out first.

This should have been implemented recently.

Hm thanks, adding a blocking task to this one then.

Some useful additional infos to the problem:
The "miss removes" consumes the amount of undo's.

Everytime when it happens, i ask me: did i hit no block or did i hit an other block? - very confusing.

Behavior has changed, the NOT gate no longer changes rail orientation on any state change.

The first issue has since been fixed, but the second issue of fleet ships being able to move into and out of noexit/noenter sectors still exists and is a problem. We use these flags for our quests and build accounts (players are locked into a sector with creative mode), so this is a bit of a problem for us as we've been having users using fleets to get out of these sectors.

Has negative side effects on Display Module functionality.

The original issue wasn't there anymore, although shop interaction (take and put in as owner) were not working properly. Buttons were greyed out when they should not have been, an ownership problem even though I was the owner.
That's fixed now.

Was fixed between releases.

In T2094#98608, @MoonDoggi wrote:

Since all of the docking/station problems are fixed, all station have now 0 mass and dos not get damage by any weapon (the projectiles hit without dmg).

Since all of the docking/station problems are fixed, all station have now 0 mass and dos not get damage by any weapon (the projectiles hit without dmg).

I couldnt pinpoint the ships involved, no, there was a lot going on around me. I havent loaded that world since, so I can probably try to track them down

In T2094#98528, @EricBlank wrote:

I ran .529 for about an hour and a half and couldnt trigger the debug script or lose any docked entities. Updating to .531 now
Again in .531 cannot seem to trigger the bug. I got loads of messages about docked entities from traders guild faction fleets losing their docks and having them moved, but none of them triggered the debug script and my fleet had no such problems

I ran .529 for about an hour and a half and couldnt trigger the debug script or lose any docked entities. Updating to .531 now

Just ran .199.531 on a game where I reinstalled starmade from scratch and then added my blueprints and server-database.

In T2094#98467, @EricBlank wrote:

In T2094#98459, @AndyP wrote:

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?

Sorry, i mean the server debug script detected something changed and shut itself down. When i went to view the bombers after reloading it all their docked entities are still attached. So i guess the bug didnt happen but the server thought it did?

In T2094#98459, @AndyP wrote:

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?

ok thank you. This is likely a false positive. I uploaded another build that will fix that. It will also notify admins, if a ship is waiting for its docks for a bigger amount of time.

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?

I replicated the bug again, this time in 199.527. did not get the admin error messages this time. Jumping around on their patrol path when they're about to offload does seem to be fairly reliable.

In T2094#98394, @schema wrote:

in 0.199.526 or later

in 0.199.526 or later

Fixed a bug where the fallback would trigger in the wrong circumstances.

thank you. this might help a lot

In T2094#98359, @schema wrote:

Please report if you encounter the admin message:
[ADMIN] (NON FATAL) WARNING: Dock for <ShipName> was not in
the right sector.
It has been moved to its mothership.
Please send in logs since this fallback shouldn't happen."

Andy you are welcome.

Now the stations are merged.

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

The attached file is a zip of the logs from trying the new pre-build.
The first time entering the world I didn't even make it in before error occured.
I tried again. Upon doing so i got many many errors flashing across the screen and red text to small to see all across the screen. So i did some looking to see what I could find before the server shut down.
i took a screen shot of what I seen. I enclosed it in the file as well.
It probably would have been better if I recorded it.
From appearances the errors happened as the ships loaded in. It appears you created a function to test if a child entity is missing from the parent from looking at the error log.
I would bet this is a database race condition as I posted in the thread.

I Know this is not my thread but i want to help.
I have version .524 and get the Admin message.
Here is the Log file.

Please report if you encounter the admin message:

I have a possible fix (0.199.524 or later).

Minion Seven was decomissioned due to losing turrets before these logs. The turrets themselves may have been floating around in the background. The fleet in question had: Minion 01, Minion 02, Underling 01, and Underling 02. (Names partially abbreviated due to my mark/version system).

Oh and another thing. I suppose the turrets aren't part of the fleet directly (as in: you added them to the fleet and then docked them)

Also, did you jump into their path? I mean, did you trigger the loading by jumping in a sector next to them directly, or did you jump into a sector that wasn't close enough for them to load so they went into loading range and loaded?

I saw a false positive in there (debug triggered shutdown because it thought there was a difference but the docking process just didn't finish)

Log zip dragged and dropped per lancake's request. The logs include a bit of unrelated building, the fleet launch, fleet debug maneuvers, a game crash, and fleet movements that include turret loss and turret return.

Could you provide logs of that session where they disappeared? Zip those up so you don't have to upload them individually. (Drag and drop the file into the comment section to upload to phabricator)

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?