Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove reset config and just make available to managers #10391

Open
wants to merge 1 commit into
base: version/main
Choose a base branch
from

Conversation

uecasm
Copy link
Contributor

@uecasm uecasm commented Nov 2, 2024

Closes discord request

Changes proposed in this pull request

  • Fixes the requestsystem reset commands blatantly lying about how much time they take.
  • Allows all colony managers to run the colony-specific reset command, since that's usually one of the first troubleshooting steps anyway when things are misbehaving.
  • Removes the canplayeruseresetcommand config setting, as it's no longer needed.
  • Displays an explicit error message for any manager-only command run by a non-manager instead of silence.

Testing

  • Yes I tested this before submitting it.
  • I also did a multiplayer test.

Review please (should port)

I considered adding an explicit TH permission setting for it, but I couldn't think of any particular reason why colony owners might want to restrict who could run it (there's a lot more dangerous things that managers can currently do anyway).

@Raycoms
Copy link
Contributor

Raycoms commented Nov 2, 2024

The reason we never made it that accessible for players is that we want them to report issues to us and not just constantly run RS reset (a lot of people already do that because they turn on the config). So I would keep that config for sure.

@uecasm
Copy link
Contributor Author

uecasm commented Nov 2, 2024

Yeah, but single-player cheats-enabled people can already run it regardless of the setting. And "bad thing happened one time and went away after a reset" is not necessarily a helpful bug report, but "bad thing happens repeatedly even after reset" is more useful.

@Raycoms
Copy link
Contributor

Raycoms commented Nov 2, 2024

Like, we have it disabled on our servers and here and there get actual useful things out of that, aside from that its maybe necessary in 1/100000 cases to run it. Running it too often can prejudice performance by a lot

@Talyda
Copy link
Contributor

Talyda commented Nov 2, 2024

We use it a lot as a troubleshooting step. If we sent every "problem" from discord to github before trying it, you'd get way more reports that wasted your time =P It's a valid step for us to see if it is just a temporary problem, or a persistent one.

And yeah, you have it disabled on the servers, but between builders that don't recognise they've been given items, them still asking for stuff that they wanted in the previous job, and the warehouse still listing things that were delivered ages ago, or waiting for requests that don't even show up on their request tab - we just sometimes really really want to be able to reset the request queue, and you guys can't be there to help out every time it futzes up (and pretty sure you wouldn't want us pinging you every time a request got stuck =P). It's incredibly frustrating to need to cancel/restart jobs, pause workers, wait for server restarts etc when it's just one of those long standing things that there is no fix for.

@Raycoms
Copy link
Contributor

Raycoms commented Nov 2, 2024

We use it a lot as a troubleshooting step. If we sent every "problem" from discord to github before trying it, you'd get way more reports that wasted your time =P It's a valid step for us to see if it is just a temporary problem, or a persistent one.

And yeah, you have it disabled on the servers, but between builders that don't recognise they've been given items, them still asking for stuff that they wanted in the previous job, and the warehouse still listing things that were delivered ages ago, or waiting for requests that don't even show up on their request tab - we just sometimes really really want to be able to reset the request queue, and you guys can't be there to help out every time it futzes up (and pretty sure you wouldn't want us pinging you every time a request got stuck =P). It's incredibly frustrating to need to cancel/restart jobs, pause workers, wait for server restarts etc when it's just one of those long standing things that there is no fix for.

yes, but if people reset this every time, us actually finding a reproduction step becomes slim to none then =D
Aside of course, the massive performance impact of recalculating all requests for larger colonies is insane

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants