Feedback:
First off, thank you for adding the crucial/none setting, it is very helpful in assessing the usability with/without any on-screen indicators.

In T2677#112703, @lancake wrote:

That's because we removed the old "X: do Y" indicators when we replaced them with the ones near your mouse. A mistake on our part since these new context ones used to be there permanently and only later in those dev builds did we add an option to fully turn them off, without realizing the old indicators weren't there to replace them.

I see. I could have sworn they weren't there before that, but...

In T2677#112558, @lancake wrote:

So should all this truly be disabled? [R] to X something was always there before and could also not be disabled. Does it get in the way or?

This is simply not true – '[R] to X' wasn't always there before 0.200, the attached screenshots are from 0.199.654#20170826_140955 aka. the latest 'pre' build, and it wasn't there in any of the 'release' or 'pre' builds before that, either. It would have driven me nuts long ago if it had been.

More testing reveals the issue is not restricted to build mode only; it also occurs when entering the pause menu ([ESC]) from flight mode, and even another level further down, in the options menu.
Similar but not identical issues I found while searching before reporting this bug were T57 and T2422, both presumed fixed.

May have been fixed in the meantime?

Apparently the file does get written when I "exit to desktop", or if the game shuts itself down in a controlled manner because of an error. It does not get written if I "exit to main menu".

My apologies, I just accidentally confirmed independently the error does in fact exist.
Went on play.star-made.org, found a shop, docked as I always do before logging out... there may now be a cluster of sectors that are inaccessible.

The file is not created or updated, regardless of single player or multiplayer.

windowPositionAndSizeConfig.tag does not generate for me when it is deleted, nor does it update with current window positions.

the same happens for ftl - transporter shield outage

I may have another puzzle piece to add.
Recently this error struck on a single player universe. I strongly suspect shipyards, specifically upsizing shipyards to accommodate a too large design that is already loaded, but I don't have proof of that - I continued to play in this world for quite a while regardless, over multiple sessions, so no chance to find any logs from then.

No idea why this is repeatedly being tagged as "Waiting on Author"; without further input from Schine or more feedback from other players, all has been said as far as I am concerned.

A bit more data:

Update: ran into the issue again.

I'm seeing this on a fresh install of 0.199.253.
Previously we had ASTEROIDS_ENABLE_DYNAMIC_PHYSICS = false, so it may have gone unnoticed if there were no collision checks happening.

Seems to be a client caching issue.

Just going to drop this here:
https://starmadedock.net/threads/mining-drone-solution.26636/

It is irrelevant insofar as the information is duplicated in other places.
However because of this lack of information in the expected places, lancake suggested I go download and install drivers when I already had the latest, and as such I see a potential issue with support, however trivial.
I know my system, and know when and how to install drivers, but someone less computer literate might follow the suggestion and get frustrated or potentially even mess up their installation when it isn't necessary in the first place.

As the shop owner, I find it surprising that if I set a sell order, the shop's sell price doesn't reflect this, but the buy price does.
What the customer gets to see is another thing entirely, but I think to me as the shop owner, the interface should coherently refer to sales prices as sales and purchase prices as purchases, no matter which part of the interface I view. If I place a buy order, I want to buy something; likewise, if I set the shop sell price, I intend to sell something to somebody at that price, and expect to find a sell order to that effect.

I wasn't sure if the setting had been intended to be repurposed for the new stars, that's why I included it in the report. If it hadn't, removing a configuration option that doesn't have any purpose might make sense and avoid confusion.

In the shop repairs menu, when you select "Repair Armor":

In T1307#64794, @Croquelune wrote:

Fungal Growth should be named "Fungal Growths" since there are several shrooms.

I disagree, it's one growth, even if it consists of multiple individuals.

I'm not familiar with the directory structure on MacOS, but for Linux at least, would you consider using ~/.config/StarMade as the cache location in order to avoid cluttering ~ ?

Confirmed, I did a fresh install of the latest dev build in an empty directory, and couldn't replicate the effect there. Maybe it has something to do with the world that has been generated years ago.

Several of the Plex Door wedge's faces show rotated and misaligned textures as well.
Current build 0.198.477, "Default" texture pack@256px resolution

Same happens with pickup/shootout rails/pickup point.

Fine with that.
I originally had it as part of my last comment in T1157, but split it off into its own task because I felt it was less about the typos, and more about making things easier for users/support staff.

blockBehaviorConfig.xml (and its derivatives):

That's to be expected, as both the server process and the client do write the config files, even if nothing has changed. Whoever goes last, wins.
As a workaround, have two installations, one for the server, one for the client.

Here are some more from server.cfg:

In T1157#43546, @Croquelune wrote:

its developers decision to spent time and effort to change it or not

Yes. But it would be definitely more mods friendly (I guess some peoples would create some launcher's skins, etc.).

found in settings.cfg: