multicraft Module: Multicraft

[fizzyjoe908]

I like what I'm hearing. Sounds like the next release, be it 3.2.2 or 3.3.0, is going to be a good one.

[fizzyjoe908]

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?

[Tyson]

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.

[Paul]

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.

[fizzyjoe908]

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.

[dkskynet]

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?

[Austin]

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

[Paul]

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.

[Austin]

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.

[Austin]

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.

[Austin]

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!

[Paul]

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?

[Austin]

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.

[Paul]

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.

[Austin]

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!

[Samistine]

Another cool feature that could be added, would be the ability to auto provision SRV records. Maybe include support for cloudflares rest DNS api

[tools]

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.

[Tyson]

The module allows you to specify a port, but only a single port, not a port range. You can still set multiple ports on a single IP to use as multiple dedicated IPs though.