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.

Huh, could have sworn at one point in time the SHP of a ship core depleted as you hit the thing... Oh well

Bug or not, needs to change a bit yeah. It's confusing, pushing in queue.

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.

Not a bug, SHP only decreases by block destruction. For the ship core that requires you to "kill" it, you'll fire through it when you've reached that point.
If the block is destroyed, it subtracts its own SHP from the pool + its own SHP * SHP penalty.

Wasn't completely fixed, moved typos/content mistakes to a google sheet.

Wasn't fixed, moved typos/content mistakes to a google sheet.

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

Ah, Schema's response on August 10th confused me. Thanks for clarifying.

@erthparadine ... not supposed to be fixed ... all those typos where moved to an outside excel sheet (or something like that) ... at least it was the plan to do that.

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?

Not resolved, note 1st line:

I do not see why not

I'm not sure, a while ago (half a year? a year?) we changed most things from block count to mass such as effects. I'm not sure if this is expected behaviour though. I'll have to ask around.

I did know how Mirror Cubes worked, just completely forgot for some reason.

Well if it's intended it's not intuitive. It may be kept as a reference but it's not shown anywhere in game.

In T1866#76040, @Spindizzi wrote:

Would be nice to have a quick checkbox of some kind to disable mirroring of anything you never tend to have more than one of (Mainly computers) rather than having to unset all the mirror planes. There;s the Mirror cube option for this but seems to be broken at the moment, has no effect on any block I try and some blocks like Scanner Computers don't mirror at all.

You mentioned several bugs, all of them known except for the "dying while in HB build block".

Not entirely sure if this is a bug.
A design is a reference to a real ship, which still has that name.
Designs can have the same name since they always point to an unique ship.

I have my doubts this is done on accident. Most likely admins enabling it themselves, do you remember any sector where a shop/station went infinite?

Correct, it's a duplicate of that task. This issue applies for all static entities (planets, stations) but it wasn't really mentioned. I'll change that now.

Should already be fixed in the latest dev builds.

Could you provide a blueprint of that ship? PM me the file ( http://phab.starma.de/conpherence/ ) if you don't want to share it with others since this is a public task.

Advanced Build mode needs lots of stuff.

-Confirmed-
got around to install a fresh Ubuntu 16.04
the created settings.cfg defaults to Pixel/128 then

good to hear it works now :)

Perfect that worked! How should I have figured that out?

Trying to reproduce

support problem and not a bug

support problem / known problem settings

Sorry, a few clarifications

• Its an 'EcryptionOperationNotPossible Exception'
• I only get it when connecting to an online server (single player works fine)
• I have uninstalled and reinstalled Java 64 bit

Still getting error

I believe many more options for display modules are planned.

Don't really see the use in this except for stations. Blueprints are after all temporary.
I will say yes to the station in center.

Its even too weak at preserving the children state.

Intended behaviour.
Faction inheritance is only applied if the docked entity has:

• no faction module (simple inheritance)
• its own faction module, BUT did not have a rank set there directly
• NO public permission or faction permission module is beside the rail OR rail docker

Logic gates: AND, NOT, OR, etc.

doesnt sound like a bug to me as such, more like a support problem.

I tested with a 101 member fleet of which the flagship contained 20 turrets.
Im unable to reproduce this in single player. fleet organisation remained the same and no member was kicked upon restart or simulated crash (shut down of SM). Move orders across sectors and then logging out did not breakup the fleet or add other entities for me.

-rejected-
i guess then there is no need for a logfile ...
as i have confirmed that it basically works on a similar system and you now having no problem anylonger it looks like a wrong setting/ broken install/ or bad network maybe.

I took the advice of a friend and tried doing a complete reinstall again and that seems to have sorted it as theirs now no issues I'm going to try and grab one of the logs from the last time it crashed due to the bug

Some new informations. A server restart solves the problem for 2 oder 3 days. Normally our server only restarts only if there is a problem.

activators do undock them in deactivation ...
no clue what you mean with linked gates ??

Does this apply to activators/linked gates as well?