Jump to content
Tyson

Module: Multicraft

Recommended Posts

If a user does decide to get the dedicated IP configurable option, how does the module handle that? Does it explicitly run an updateServer API call and set the port to 25565?

 

The module will select the first available dedicated IP and daemon from the list you've defined in the module, and set the server to them. Multicraft chooses the port.

Share this post


Link to post
Share on other sites

The module will select the first available dedicated IP and daemon from the list you've defined in the module, and set the server to them. Multicraft chooses the port.

 

Does Multicraft default to port 25565 if no other servers exist on the IP? Since the default behavior was that it increments the port number, I would assume so. People paying for a dedicated IP address are going to typically expect it to be on the default port.

Share this post


Link to post
Share on other sites

Does Multicraft default to port 25565 if no other servers exist on the IP? Since the default behavior was that it increments the port number, I would assume so. People paying for a dedicated IP address are going to typically expect it to be on the default port.

 

Multicraft will default to whatever port number is configured as the default port. Multicraft ships with 25565 as the default port but it can be changed.

Share this post


Link to post
Share on other sites

I added the multiple Daemon ID improvement to CORE-1329. I'd like to discuss the multiple IP address / port provisioning recommendations with Tyson before I create a task on that. If anyone has anything to add, please chime in.

 

As for the Multicraft account (And FTP), the account is created when the first server is provisioned for the account, and this email should contain the login details for Multicraft. Subsequent servers are added to the same account, and the Multicraft login details are unknown by the service so they are not included.

 

This can be handled in the welcome email by using a conditional statement or a note to say that it's the same login as the previous servers.

 

We are working on a feature where modules may share information between services, and I hope to have this in 3.3. This would allow a 2nd, 3rd, etc server to include the same login details as the first.

 

My Multicraft and FTP do not create the same password for blesta and Multicraft!! Is there anyone who can say why?

Share this post


Link to post
Share on other sites

Since both Blesta and Multicraft password differ, maybe the module can have a way for clients to change their password from within Blesta?

 

Just a thought :)

 

This should be possible with the system we created in 3.3 that allows a module to "share" data between services. The module would create the view to change the password, and all services would recognize the change. Of course, Multicraft has to be updated in order to take advantage of this.

Share this post


Link to post
Share on other sites

Another quick idea: the ability to allow custom player slots on adding a package. In addition to allowing it as a configurable option, I think it should also be allowed to tick a box to enable it when adding a package itself.

Share this post


Link to post
Share on other sites

This should be possible with the system we created in 3.3 that allows a module to "share" data between services. The module would create the view to change the password, and all services would recognize the change. Of course, Multicraft has to be updated in order to take advantage of this.

I spoke with rhe developers and this is currently possible I guess. Through the UpdateUser API function this should be possible, so it may be a nice addition for s future release.

Share this post


Link to post
Share on other sites

Enhancement idea:

A better way to manage servers, something along the lines of how the Interworx module handles things. Currently, if a server is at capacity I can set it to load any new order onto another via the daemon id, which is fine. However when a package is created it will use the IP of the server set for that package. Therefore I have to change the server every time one becomes full, simply to have new order emails reflect the correct information.

This is slightly annoying and could cause issues if large volumes of orders are being placed, as customers would be being put on the correct node but the IP set for the server would reflect the incorrect one.

If I'm overlooking something please correct me!

Share this post


Link to post
Share on other sites

Enhancement idea:

A better way to manage servers, something along the lines of how the Interworx module handles things. Currently, if a server is at capacity I can set it to load any new order onto another via the daemon id, which is fine. However when a package is created it will use the IP of the server set for that package. Therefore I have to change the server every time one becomes full, simply to have new order emails reflect the correct information.

This is slightly annoying and could cause issues if large volumes of orders are being placed, as customers would be being put on the correct node but the IP set for the server would reflect the incorrect one.

If I'm overlooking something please correct me!

 

Do you have multiple Multicraft master servers?

Share this post


Link to post
Share on other sites

Nope, I have the interface running completely separate from where any Minecraft instances are running. Currently have 2 daemons, and just encountered this issue on a recent order.

 

You can create a configurable option for daemon_id and list multiple daemon ID's in there, separated by a comma. People use this for adding an option during checkout for like "Location", where say Los Angeles is a location, but multiple different Daemon IDs are associated with it. Then, the Daemon ID with the most available resources is used to provision the new server.

 

See http://docs.blesta.com/display/user/Multicraft#Multicraft-ConfigurableOptionsOverview

 

Do you think this would solve it? Maybe I misunderstand the issue.

Share this post


Link to post
Share on other sites

You can create a configurable option for daemon_id and list multiple daemon ID's in there, separated by a comma. People use this for adding an option during checkout for like "Location", where say Los Angeles is a location, but multiple different Daemon IDs are associated with it. Then, the Daemon ID with the most available resources is used to provision the new server.

 

See http://docs.blesta.com/display/user/Multicraft#Multicraft-ConfigurableOptionsOverview

 

Do you think this would solve it? Maybe I misunderstand the issue.

I think I solved the issue, I did have two master servers setup in Blesta. Issue resolved/avoided, thanks Paul! :)

Share this post


Link to post
Share on other sites

Hello,

I see an option for a dedicated IP,
would it be possible with a dedicated port pool also?

I'm hoping to provision multicraft behind NAT,
that's why every dedicated machine would need a pool routed.

i.e.
10.0.0.1 - webhost,
10.0.0.2 - multicraft host, pool port routed 25100-25199
10.0.0.3 - multicraft host, pool port routed 25200-25299
and so on.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...