please check for a folder in C:\Program Files (x86)\Steam\steamapps\common\StarMade named .cache and delete it, then try again.
if that isnt working redownload the Launcher and replace the current one.
if its still not working start it with "\sta0rmade-launcher.exe --verbose" as option and add the launcher.log from the launcher install path here (just drag and drop it in then)

I've had this and it was also with the ship menu, didn't post at first as I couldn't reliably reproduce it, had a couple of null pointer exits to menu but I could go back and do all sorts without it happening again.

How about a block CV to the docking rail point with a gui menu pops up and let you select if the rail is set to "ship part" or "drone/fighter"?
Or some logic setup? eg. C rail V AND as "ship part" and C rail V NOT as "drone/fighter"?

Sadly this is 6 of 1 half dozen the other... Any way to differentiate docked engine nacelles and drones and fighters?

-validated-

The old thruster plumes usually worked on docked entities. It either always went 100% throttle or never appeared if I recall correctly.
Not sure if what we currently is a bug but it's certainly worth changing.

Thanks for your swift response AndyP.

As a side note, when you updated from 214 to 234 with the new launcher, did it download a decent amount of files? It could have been that it was correctly updated but the launcher still thought it was your downgraded version. If that was the case, it should barely have downloaded a file, maybe 1, when you upgraded to 234.

Could be user error (somehow..), it's a really strange issue and this is the 1st time I hear about it. I tried checking it myself but it updated just fine for me and I can only check it once per release.

There are quite some settings that should cause problems.

I see, only happens if you want to undock immediately after a dimension change. Thanks for the feedback!

This bug can be reproduced by the following. All rails will be pointing up(the y) for this example and in the same x-z facing unless stated otherwise.

• Validated -

Open for testing.

I started with a 59 block line in +z, 53 blocks in +x and 53 blocks in +y direction, all with a single click. This should go beyond the 96 x 96 x 96 box, since 96 / 2 = 48 < 53. Then I added 53 block lines in -y and -z direction, again with a single click.

-confirmed-

Thank you for the logs but I need them from the server itself.

Side note, in the dev builds after the 0.199.217 release, the Tab debug button was moved to F1.
(so it's F1 + F8 and F1 + G now)

Hm, I've been noticing (minor) stuttering with small enough weapon sizes too now.
My fps doesn't really drop, from 200 to 160 which is within expected ranges when killing blocks.

A ship core starts with 3 x 3 x 3 chunks initialized if I remember correctly. That should be a 96 x 96 x 96 box with the ship core in the middle.
A single 50m long line wouldn't trigger new chunks since the area being used is already initialized. 100m would though.

I made a test entity, one 50+ long line in the x-direction and one in the z-direction, without any problems. Then I added another line in the z-direction, which turned all blocks in a 9 block radius around the core unphysical. I don't see any relation to chunk borders, and the problem occured in a place that worked before, it's even the core chunk, so I don't think it's related to uninitialized chunks, at least not directly. Also, the extent of the unphysical part changes when adding more blocks.

...Well found the problem then. The partition is 100GB in size to separate out steam libraries in case 1 or other fails to load a game as is something that has happened in the past.

Pretty sure this is a duplicate of T758. Placing in new chunks (you're probably looking at a chunk border) can cause the block to appear non physical for your build mode stuff. Changing the camera rotation will hit the physical part and the game will then try to put it in the correct spot.

Changing claim back, looks like we both did this task at the same time.

Your logs mention that there is not enough space on "the disk". Is your partition full?
As for the javascript error, that's something from the launcher. Not sure if that's a real issue considering it only seems to pop up after this particular "crash".

-Feedback-
[2016-09-20 12:27:59] java.io.IOException: There is not enough space on the disk

I think I may know what is the cause now.

Whoops...Merged the wrong task.

Duplicate, it's confusing as there's little to no difference between weighted mass true or false. The rotational values will never change (since it always checks for the ship core's position, not center of mass).

With the recent optimizations, it's far from "extreme" lag now. It seems like it doesn't affect performance now except that there are these weird freezes for a small amount of time each volley.

When testing in current release, the test ship and target half FPS from 45 to 23 while blocks are being destroyed.

Can do, At least the new Launcher allows hotswapping much easier and faster. A few patches ago the single player F7 lag statistics on HUD has also been stuttering occasionally, when at one point the game showed no load (A flat line) when in single player indicating that the server was having no issues at all almost all the time.

A part of this issue was fixed a while ago. The lag compensation handles it well inside a sector, no warping back and forth going on.
Beam targeting was also improved and phasing through ships shouldn't happen anymore at larger distances. (T91)

Hm, so it goes downhill the longer you fire it at once?
Sounds like the server (in this case, your SP) can't keep up with the block destruction and is queuing more and more till it bogs down.
You'll notice that on planets with a large enough salvage group.

In T1669#73357, @33Cav wrote:

Another issue I have also noticed that it takes quite some time after exiting to main menu before memory is de-allocated from the StarMade process (if at all). Entering back into a world (the same MP server as I was just on in this case) has the previously "used" memory counted as "used" still and now new memory is being taken up reloading chunks in the world. As a consequence of this I usually have to restart the entire game to free up the memory or risk poor performance (in the form of repeated game freezes) when the StarMade process dumps the older memory when I near my max memory allocation amount.
Hopefully you can get something useful from my description.

It was working fine before the chunk 32 update. After that it broke.
Most likely the "respawn shopkeep" function is still located at its old block coordinates and wasn't moved to its new position after the chunk 32 update.

Still not sure what would cause it. Can't confirm for Nvidia, that report might be incorrect if that person was accidentally using intel HD graphics.

The supposed BB death only happened once, I've been unable to duplicate. Maybe something wonky did happen like accidentally getting out.

From ongoing player discussions, is it possible to distill this issue down to something simpler: considering that there was a very obvious shift to 6-digit metaobject IDs in release 0.199.217. Are client requests for 4-digit metaobjects simply resulting in an odd search/response behavior from the server?