-Validated- & -Confirmed-

-validated-
-confirmed-

-Validated- & -Confirmed-

-Validated- & -Confirmed-

1. It's rather a C than a U
2. Yes
3. Yes

i know the chat was shown on screen when all channels where closed.
not sure when that did chang.

W.T.F... I don't think you're doing anything wrong @SmilingDemon . As I can get the annoying #general chatter to go away now by clicking "close". I could have sworn I tried testing this in the past though...but honestly didn't specifically try with the current production version until your comment.

Good find.

Reported by AtraUnam, keeping it on private since it can cause server crashes in some cases.

Hm, it was more or less known, just not reported :(
Your description has everything I found so I'll just edit the steps to reproduce a bit and then push it in queue.

Alright, I did that many times before and that never caused this issue hm... This task is a duplicate of T1123 btw so I'll most likely merge them. We tried many different situations yet no results, it might just be random.

alright same for me too. Want to make sure it still works fine for AMD without bloom though.

No feedback to latest response.

That's possible, unfortunately the linked thread isn't that clear. Google translate tried its best but doesn't make much sense to me unfortunately.

Apparently this happens when the server wants to send a null as server message. How that message got null though, no idea. Perhaps the language pack is missing entries but that should give you issues on startup so I doubt it.

Spawned in a big ship with plenty of turrets and docks, when the mothership was despawned. Some of the turrets/docks were non physical, others were fine.

Thought we already had it reported but can't find it, the closest we have to it is T64.

Taking over and pushing in queue.
New logs from the test server:

-Feedback-
do i get that right

• you use a U shaped shipyard
• when building a design in there you can build past the outline of the U
• the design does get build into a ship by the shipyard when given the build command ?

Well the ship got on the takeoff rails these red ones when the ship got on top of the line of the takoff rails i added some more takeoff rails and i placed them before the ship reached the end.

-Feedback-
Please add the following

• a logfile of one of those crashes (found in starmade/logs, named log.txt.x)
• a description of the used hardware on server and client (is server and client running on the same system?)
• a blueprint of what was shoot at and a blueprint of the weapon that did shoot (assuming you already have a sample here)

No feedback.

I'm not exactly sure what steps you did to get this result. Did you add red rails to other red rails while a ship was moving on them? And did you add them before the ship reached the end or after?

check T1143 for the AI thing

-validated-
make sure that overheated fleet ships are still removed from the fleet as a member and its AI offline (maybe that is broken again here)

-validated-
agree that the permission module should only be required on the shipyard controller

The server is now off line, But at their hay day they reminded me a lot like yours, 10-25 players at least. Anything that cause lag was prohibited. That was the excuse for having only one BP per player. The server was mike lands btw.

In T1401#55082, @Chandler wrote:

I was thinking the same. Other servers limit players to 0ne BP at a time.

Confirmed on Dev Server. Although there is not a red error, just the quick spike. I am of the opinion that this has to do with the size of the blueprint catalog. The greater the size, the greater the lag...

In T1401#55080, @erthparadine wrote:

Maybe @Raiben could throw some info here then.
As for StarBits, after the reset we started fresh with just the Vanilla Isanth series of blueprints. We're already back up to 225 blueprints, but no noticeable lag yet.
Random thought: I wonder if the breaking point is 1024 blueprints?

Maybe @Raiben could throw some info here then.

In T1401#55056, @erthparadine wrote:

In T1401#55053, @Benevolent27 wrote:

...
Another server I tried, StarBits, was having this same issue, and they also deleted all their blueprints.

stars.bitminery.com = StarBits
To reiterate: upon a reset of our blueprint database, the blueprint related lag went away.

In T1387#54407, @lancake wrote:

For anyone subscribed to this task, you can still move the build helper by using an other bug to your advantage: T242
Basically "copy" the ship core (or any other block) with an active build helper and then paste it where you want the build helper to move.

Another whole-server hang today. Lasted until I manually deleted one of the asteroids...went through a few of them until finally finding the correct one, and then the lag immediately disappeared.

-Validated-
-Confirmed-

Ok i dont get it, using this

In T1401#55053, @Benevolent27 wrote:

...
Another server I tried, StarBits, was having this same issue, and they also deleted all their blueprints.

stars.bitminery.com = StarBits

I probably didn't have a faction module on the ship I was picking up, during my earlier listed steps. Since, it was just a quickly built test ship. Apparently that makes a difference.

We had this problem on my server as well, StarSide. They even deleted all the blueprints and the problem is still happening.

Apparently the trick to reproducing this is that the unmanned ship NOT have a faction. When I had encountered this, I was sending a basic stick ship (with no faction module or tag) toward a pickup point and pickup rail on a factioned station. Under those circumstances it gets stuck on the pickup rail until reloading (this was in single-player).

I've posted a suggestion there before which was well received, although that one proposed a very broadly-sweeping change...figured the simpler requests would go here. I'll stick to the forums in the future, thanks for the pointer.