starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 14:15:59 +03:00

[GH-ISSUE #1654] Disable Lua-AutoRefresh by default on gmodserver #1290

New issue

Closed

opened 2026-02-27 02:56:19 +03:00 by kerem · 9 comments

kerem commented

2026-02-27 02:56:19 +03:00

Owner

Originally created by @MarkTwoFive on GitHub (Oct 18, 2017).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1654

Originally assigned to: @marvinlehmann on GitHub.

Reason: Lua files are being refreshed when file changes are detected (Actually saving or just permission changes as any write operation triggers the refresh).

This is not supported or recommended by GarrysMod.

I suggest adding "-disableluarefresh" to the default parameters as the auto refresh should only be used during development processes. This will force users to restart upon changing scripts causing more consistent, reliable and supported behavior and preventing inconsistent bugs.

See: https://wiki.garrysmod.com/page/Auto_Refresh

Originally created by @MarkTwoFive on GitHub (Oct 18, 2017). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/1654 Originally assigned to: @marvinlehmann on GitHub. Reason: Lua files are being refreshed when file changes are detected (Actually saving or just permission changes as any write operation triggers the refresh). This is not supported or recommended by GarrysMod. I suggest adding "-disableluarefresh" to the default parameters as the auto refresh should only be used during development processes. This will force users to restart upon changing scripts causing more consistent, reliable and supported behavior and preventing inconsistent bugs. See: https://wiki.garrysmod.com/page/Auto_Refresh

kerem

2026-02-27 02:56:19 +03:00

closed this issue
added the
type: feature
label

kerem commented

2026-02-27 02:56:20 +03:00

Author

Owner

@UltimateByte commented on GitHub (Oct 19, 2017):

Well, if it wasn't supported it would be disabled by default, don't you think? In some cases it saves time, in other cases it will crash your server while adding/editing scripts, especially when you make syntax errors of course. Though I agree it can be nice to have it by default, and users can just remove the argument if they don't like it.

(just to make sure all things are considered before committing)

@UltimateByte commented on GitHub (Oct 19, 2017): Well, if it wasn't supported it would be disabled by default, don't you think? In some cases it saves time, in other cases it will crash your server while adding/editing scripts, especially when you make syntax errors of course. Though I agree it can be nice to have it by default, and users can just remove the argument if they don't like it. (just to make sure all things are considered before committing)

kerem commented

2026-02-27 02:56:20 +03:00

Author

Owner

@MarkTwoFive commented on GitHub (Oct 19, 2017):

I've indeed thought about that too.

Hopefully you won't be editing either you other 3rd party scripts on a production environment though. Fixing syntax errors can also be very tricky because as said in the article when refreshing cascades some of the initializations are redone and some aren't which always may break everything in weird manners. For the same reason reloading in MC servers should only be used in development environments.

At least to me the deployed lgsm server should not be a development server out of the box. Features soly for development should be disabled.

Just to respond to your concerns.

@MarkTwoFive commented on GitHub (Oct 19, 2017): I've indeed thought about that too. Hopefully you won't be editing either you other 3rd party scripts on a production environment though. Fixing syntax errors can also be very tricky because as said in the article when refreshing cascades some of the initializations are redone and some aren't which always may break everything in weird manners. For the same reason reloading in MC servers should only be used in development environments. At least to me the deployed lgsm server should not be a development server out of the box. Features soly for development should be disabled. Just to respond to your concerns.

kerem commented

2026-02-27 02:56:20 +03:00

Author

Owner

@marvinlehmann commented on GitHub (Oct 19, 2017):

I just saw that it was actually discussed long ago #590 but I still agree with @MarkL4YG although my knowledge about gmod is quite limited.

@marvinlehmann commented on GitHub (Oct 19, 2017): I just saw that it was actually discussed long ago #590 but I still agree with @MarkL4YG although my knowledge about gmod is quite limited.

kerem commented

2026-02-27 02:56:20 +03:00

Author

Owner

@MarkTwoFive commented on GitHub (Oct 19, 2017):

Yeah.
It seems the focus there was more a switch for this though rather than just adding the parameter to the default params.

Also it seems that issue is one of the first appearances of the additional params option - nice to know 😃

@MarkTwoFive commented on GitHub (Oct 19, 2017): Yeah. It seems the focus there was more a switch for this though rather than just adding the parameter to the default params. Also it seems that issue is one of the first appearances of the additional params option - nice to know :smiley:

kerem commented

2026-02-27 02:56:20 +03:00

Author

Owner

@UltimateByte commented on GitHub (Oct 19, 2017):

On #590 the lua autorefresh was just being added to the Linux version of Gmod server, so the point of view was a bit biased. Yeah, this idea of additional_parms which later became customparms, came from seing multiple request for parms that people might want to change but were a bit questionable to be added by default.
You're very right to remind it, customparms variable would fit perfectly for this case.

@marvinlehmann In that regard, it would be better to add it within customparms="" rather than in main parms="".

@UltimateByte commented on GitHub (Oct 19, 2017): On #590 the lua autorefresh was just being added to the Linux version of Gmod server, so the point of view was a bit biased. Yeah, this idea of `additional_parms` which later became `customparms`, came from seing multiple request for parms that people might want to change but were a bit questionable to be added by default. You're very right to remind it, `customparms` variable would fit perfectly for this case. @marvinlehmann In that regard, it would be better to add it within `customparms=""` rather than in main `parms=""`.

kerem commented

2026-02-27 02:56:20 +03:00

Author

Owner

@MarkTwoFive commented on GitHub (Oct 19, 2017):

@UltimateByte that may well be a compromise between adding it to the default params and not adding it at all.
But honestly wouldn't that compromise the purpose of "custom"-params on the other hand? One big question with this param and LGSM should really be how LGSM wants to deploy servers: In development or production stage.

@MarkTwoFive commented on GitHub (Oct 19, 2017): @UltimateByte that may well be a compromise between adding it to the default params and not adding it at all. But honestly wouldn't that compromise the purpose of "custom"-params on the other hand? One big question with this param and LGSM should really be how LGSM wants to deploy servers: In development or production stage.

kerem commented

2026-02-27 02:56:20 +03:00

Author

Owner

@marvinlehmann commented on GitHub (Oct 19, 2017):

@UltimateByte Done it. I totally didn't see it >.>

@marvinlehmann commented on GitHub (Oct 19, 2017): @UltimateByte Done it. I totally didn't see it >.>

kerem commented

2026-02-27 02:56:20 +03:00

Author

Owner

@UltimateByte commented on GitHub (Oct 20, 2017):

This is now merged.
(Into dev and will be into the next release)

@UltimateByte commented on GitHub (Oct 20, 2017): This is now merged. (Into dev and will be into the next release)

kerem commented

2026-02-27 02:56:20 +03:00

Author

Owner

@lock[bot] commented on GitHub (Oct 20, 2018):

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock[bot] commented on GitHub (Oct 20, 2018): This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.