Enable autostart of servers from within app

[thomasfinstad]

Is your feature request related to a problem? Please describe. While it is grand to have auto-mcs running on a remote host and manage via telepath, when creating a new server, that server will not autostart until logging into the remote host to change the startup parameters of auto-mcs to add it to the launch option.

Describe the solution you'd like An option to enable autostart of servers from within the application itself, much like how enabling auto update is currently handled per server.

Describe alternatives you've considered Create a cron job that looks at the Servers folder to find all servers, then automatically start them all X minutes after a host reboot. Extremely cumbersome, and becomes an "all or nothing" approach.

[macarooni-man]

@thomasfinstad you can already do this using the --launch flag, its detailed in the server manager guide, which can be used from a cron job

The biggest problem with auto start is auto-mcs would need a service. That's not a simple thing to implement unfortunately, and not something I wish to implement

[thomasfinstad]

@macarooni-man I think you misunderstood my request, not your fault, I'll reword it here to hopefully make what I meant clearer.

• Host: remote VM running auto-mcs via docker compose (automatically started on boot)
• Server: minecraft server instance under control of auto-mcs

What I wish is to not need to login to the host and change the --launch flag if I create a new minecraft server instance that should automatically launch when the vm host reboots (for example after a system update).

Currently I would have to either login to the host and add the new minecraft server instance to the --launch parameter manually. Or open auto-mcs, connect via telepath and manually start the minecraft server instance.

In auto-mcs under the minecraft serverinstance there is a simple toggle to "auto update" the the server instance, I would love a similar toggle that would enable auto-mcs to start the minecraft server instance automatically without needing to change the --launch parameter.

auto-mcs is started automatically on boot of the vm host no problem, but unless I change the compose.yml file with a modified --launch parameter, new minecraft server instances will not start automatically.

Let me know if anything is unclear.

[macarooni-man]

@thomasfinstad no it's not unclear, but I appreciate that you elaborated. The issue I have with adding a UI element is that most people would assume that it would start with your computer by default if you enabled that option, and they likely wouldn't try to schedule a task or cron job because it "doesn't work". While I'm not opposed to your suggestion, to make it accessible would require a service, and currently, I can't justify that for this use case without changing the architecture of the app itself. Most people would assume it doesn't work and would never use it, and it would take up space in the UI for no reason.

However, you bring up an interesting point with Docker. It's more justifiable to me to add a command line option in headless to get the functionality you suggest, the people who are using that interface are likely under the expectation of what you suggested. Would this work for you?

[thomasfinstad]

@macarooni-man I am not picky about it, anything would work for me, just thought the gui option would be the most elegant in general. It might be easier to understand if it is not called "autostart", but rather something in the vein of "start with auto-mcs" or "launch when auto-mcs is started". But really anything would work for me personally.

[MovementGH]

I ran into this same issue and made a simple patch so that using --launch all launches all available servers. Tested on docker (where I am using auto-mcs) and it is working for me. Is this something you would be interested in a PR for?

[macarooni-man]

I ran into this same issue and made a simple patch so that using --launch all launches all available servers. Tested on docker (where I am using auto-mcs) and it is working for me. Is this something you would be interested in a PR for?

Hi there @MovementGH, thanks for your interest and the patch!

First of all, I wanted to mention that this is also a really great idea! Unfortunately, I can’t accept that patch as-is since your fork is against main. The launch code there has already been fully replaced in dev and I’d have to re-implement since the codebases are completely different now. If you'd like to contribute in the future, please see the Contributing Guidelines as PR's & patches need to be based on dev specifically for this reason; they frequently diverge.

Additionally, to be frank, even with the patches I've made in dev I don't think it's a great idea to polish this system. The --launch flag was really just a band-aid for a lack of a better solution, and bolting on extra features without addressing the core problems with it is not a scalable solution in my opinion. However, as you and others have noticed, it does certainly provide a useful feature, but with some limitations.

At this time, considering there are a lot of challenges I'd like to address on top of both of your concerns, I believe that this system warrants a full redesign for scalability. The biggest challenges that I'd like to resolve are:

• The --launch logic for headless and the desktop UI are two completely different branches that utilize similar code, though with a different notification system. This can make debugging more challenging, and I would like to unify them in ServerManager, with a callback to the UI dependent notification systems

• Using "all" as a parameter would break if a user named their server "all". A non-filesystem character like a wildcard --launch * is more effective due to the fact that it would never interfere with a file name

• If you have a lot of servers, RAM is a serious concern. At least for me, I have a lot lol. I'd like to do a projected memory cost to see if it's possible to launch them all first without killing the page file

• No matter what, they will need to launch sequentially to prevent port conflicts. This can get extremely slow with large servers, or a large amount of servers. Another alternative is to abstract the logic that detects port conflicts during the launch sequence in the ServerManager and map the network utilization in advance so that they can indeed be launched concurrently.

• And of course, adding an autostart parameter to the config file globally throughout core.foundry, core.manager, a button for desktop, and a command for headless to configure it

With that being said, my focus is with refactoring the UI at the moment. If you'd like to help out with what I've mentioned above, I'd be happy to discuss more in detail. It's easier to reach me on Discord!