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

[Feature] auto allocation of more than one port for e.g. source games #841

Open
AleXburnA opened this issue May 16, 2023 · 2 comments
Open
Labels
Feature Adding a new feature, or substantial improvements on existing functionality Low Priority Can wait, not urgent. Handle when possible

Comments

@AleXburnA
Copy link

AleXburnA commented May 16, 2023

Feature Description

Certain pterodactyl eggs needs more than one port to function properly (e.g. ARK needs four: main, main+1, rcon and query port).

While its possible to add more than one port allocation to a product, the user still needs to do several steps by hand, after the server is deployed:

  • go to the pterodactyl panel and manually add the two additional ports
  • and then manually change the variables for rcon and query ports to match with those which got allocated

as this breaks the automated deployment of such eggs, it would be nice to have a solution for that.

Solution Idea

it would be great if there would be a way to customize egg parameters at the product setup. There should be a way to auto-allocate additional ports and map it to specified variables of the eggs.

A feasible way could be:
1.) POST to https://{{HOST}}/api/client/servers/{{SERVER_ID}}/network/allocations to assign the allocations to the server.
2.) PATCH to https://{{HOST}}/api/application/servers/{{SERVER_APPID}}/startup to update the servers variables with the learned port numbers.

There are also games which also need Gameport + 1 to function, for example Valheim or ARK. So it would be nice to handle those cases as well. <-- I've learned that those ports are optional and not really required, and there are also limitations on the pterodactyl side, so this part is not that important.

Additional Info

We had a discussion in Discord about this feature: https://discord.com/channels/787829714483019826/1108138041790431435

@AleXburnA AleXburnA added the Feature Adding a new feature, or substantial improvements on existing functionality label May 16, 2023
@AGuyNamedJens
Copy link
Collaborator

I don't think we can easily implement this considering the fact pterodactyl/panel#1653 it's actually not even implemented in pterodactyl themselves?

However, there's always a way to firstly create the product then later on update it via code..

@AleXburnA
Copy link
Author

AleXburnA commented May 24, 2023

Yeah I recently saw this feature request. I've also just learned that gameport+1 is optional, so this wouldn't be a big showstopper.

But the other feature (update specified servers variables, e.g. RCON and Query Port, with the actual allocations) is pretty important IMO as it currently prevents ctrlpanel from being usable for games with more than one port.

This can be done with the API, I just tried it myself with postman:

1.) POST to https://{{HOST}}/api/client/servers/{{SERVER_ID}}/network/allocations to assign the allocations to the server.
2.) PATCH to https://{{HOST}}/api/application/servers/{{SERVER_APPID}}/startup to update the servers variables with the learned port numbers.

Maybe this has to be done after the server has finished installing. I am not too sure how hard it is to implement a "watcher" in ctrlpanel which waits until the server has finished installing before it does the reconfiguration.

I've updated the feature request to reflect the current state of knowledge. :)

@S0ly S0ly added the Low Priority Can wait, not urgent. Handle when possible label May 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Adding a new feature, or substantial improvements on existing functionality Low Priority Can wait, not urgent. Handle when possible
Projects
None yet
Development

No branches or pull requests

3 participants