Config and log attached.

On second thought, we probably don't want a task for every little translation line gone wrong for a specific language pack...Rejecting this task. If more pop up, we'll put it in some google doc maybe or on just 1 phabricator task we'll never close.

Found the error in the translation pack, I fixed it and approved that instead. Next release should fetch the updated file but putting it on resolved now.

-rejected-

Debatable. Thrust affects network traffic a lot, the more thrust you have, the more sectors will get loaded/unloaded on average. I'll poke schema about it to see what he thinks but a bug task seems overkill.

That's odd. It's not meant to migrate all your blueprints if you join a MP server since they aren't being used. If you upload one, it converts just that one. It worked back in one of the dev builds but heard someone mentioning the same thing so this can't be a coincidence.

I guess this belongs in queue ;)

In T1799#69918, @calani wrote:

Addendum:

"Currently, the launcher bundles a bunch of game files which are basically outdated and must be overwritten/updated before players can run the game anyways."

No. The launcher package only contains the launcher itself (Electron+launcher code) and the bundled java. The only game-related file is a .txt containing the game's steam app id... which isn't being used.
Unless you're referring to downloading the game via Steam? in which case, yes, the depot contains the most recent release build of the game. Changing this behavior would be silly, as you would be unable to play the game after "installing" it via Steam. (Steam would then also not delete the game files if you asked it to uninstall the game.)

"Currently, the launcher bundles a bunch of game files which are basically outdated and must be overwritten/updated before players can run the game anyways."

The larger issue is that this also applies to the game itself.

Sounds more to me they want to further close their ecosystem.

-validated-
-confirmed-

OK ..will put it in queue with my test observations ... still have no clear idea what the intended way how trigger areas should work was .. but i guess
Schema will know ;)

I am just wondering, is it due to some memory leak or something (quite difficult in Java tho...)?

I want to detect parts of the docked ship from the station to identify which ship is going over the belt and then route it to its destination using that information. (e.g. park ships in the ship parking and park cargo pods in the cargo area)

I'd be willing to make you a gif if you'd like.

It's both with single blocks and large chunks with symmetry. Almost the same lag time, also. THe image of the placed block remaing but it's not registered. Would you like me to make some gifs and plug them in here?

As this issue goes on, I'm seeing stronger correlations between this ticket, T1664, and T1712. Perhaps consider merging all of them into one?

Asteroid spawning/respawning appears to be the cause behind GenX's most recent rash of crashing as well. Unknown if @bobbybighoof has respawn enabled/disabled, but their logs show a distinct pattern of asteroid AABB checks, immediately followed by a ping/pong death spiral.

it does save fine to the settings.cfg
(G_SINGLEPLAYER_CREATIVE_MODE = false //creative mode)

Just chiming in for extra info, it's a bug with slot 1 on the hotbar.

Your server is running out of memory

in case you wanted to detect the core without a player controlling it, the area trigger is not designed to do that.

ok rejecting this than for now

works just fine

not happening ... not local or on the testserver

i am having this same issue right now. it has made the ship yard i spent the last 2 days build very broken. is there a fix?

This is my first report, so I don't know what additional information is relevant.

I never considered this as a bug but it might be one, doubt it though.
Schema can reject this task if it's intended for now (or implement it to improve it).

Only happens with a response fleet, newly made blueprints are fine and only the converted ones are affected.

-validated-

It's the star squadron server. The problem starts here and it just keeps throwing out these errors until the server dies.

and what server is that ?

Some more log files if it helps. We have an entire region on our server afflicted by this issue since the chunk update. The only solution I've found is to delete every offending sector but I keep finding more.

With the 32 size chunks this seems to happen less often.

more a support problem than a bug

While I don't support the current permission system it is what we have to work with so I am voting yes.

The newsletter has been discontinued; we may resume it in the future.