Sponge Server Launcher?

Do you guys be ok if the servers running on Sponge would have better launcher/running GUI than the default ones that Mojang have for the server GUI?

I was planning on creating a server Launcher app entirely in C# made in Visual Studio 2013 (and 2014 if I can get it off Dreamspark website when it get released). The app will be open sourced on (GitHub) so the Sponge Devs or anyone can edit it if they want to.

For the launcher there are the list of the features:

  • can download new server “Jars” from the launcher itself
  • be able to restart/shutdown the server
  • config the server options from the GUI rather than opening a file in notepad and edit it
  • manage your plugins from the GUI
  • see errors in separate list rather than having it shoved in the same window as the chat log (while the server is running)
  • be tablet-compatible for people who want to access it when their server is either on the tablet, desktops, laptops/ convertibles or on the server hardware.

I will post screenshots and videos of what I’m talking about later on this post.

So, what do you guys and gals think about my idea?
EDIT: I changed from C++ to C# because most of the universal app don’t work in without more research on C++ like the Settings flyout.

1 Like

Not a bad idea, however this has already been discussed here. However there are a few flaws. It would be quite a bit slower. Also personally I think it’s less configurable.

That would be nice, as long as you open source it.

1 Like

Why Visual Studios. Plus it’d be only windows dependent. Though c++ is my strongest language I’d definitely help out, just Makefiles fit better here. Overall this isn’t a bad idea, but make the launcher an optional thing is my say, let people do whatever they want.

There’s already a topic discussing this Sponge Should Have a GUI

You may also be interested in BukkitGUI (source code) which will likely support Sponge.

I have Visual Studio 2013 Pro for free from Dream spark Website. So that’s why I was originally planned to work with that but the nice thing is Microsoft is planning to make Visual Studio projects target multiple platforms in the future with 3rd party SDK. So for now, the first platform to be released on for this project will be Windows. Then in the future it will be converted to cross-platform based.

1 Like

Or you could just make files which are way better. I mean it’s just always better, you don’t have to deal with a new system still getting it’s footing. You can use a widely acclaimed system, that has tons of footing.

I updated the github repo with new apps. apparently, Visual Studio complains something about the Settings Flyout thing for Windows 8.1. I was targeting for both Windows 8.1 and Windows Phone as of now.

If you write it in C#, it will be Windows dependent. Most servers are run on Linux. Typically, Linux servers don’t need GUI’s or are on hosted solutions that have some other form of GUI for their clients. This could be a niche thing for people who run servers on their Windows desktop, but you still alienate people who run them on their Mac or Linux desktops. Make your launcher in a cross platform library like LibGDX (Java) or Kivy (Python), to name a few examples.

1 Like

He’s using C++. The problem is he is using Visual Studio’s, and not Makefiles. He could use a cross-platform GUI system such as QT, or some other manager with Makefiles, and have it run great on any OS. Though I don’t see that happening. Though your right for the person wanting to run a home server it could be useful. Also @Lucas_Davies why are you targeting windows phones? Is the windows phone going to run the server?

I was taking advantage of Universal App idea so I don’t have to rewrite the app from scratch, if I ever want to port the server control panel part of the app to Windows Phone, so the Windows Phone version would be limited to controlling the server from desktop, laptop, etc. due to OS limitations of Windows Phone. And the other thing, I’m changed from C++ to C# due the Settings FlyOut issue in the first place and the other unknown issue on the behalf of Visual Studio’s C# error log rose after changing to C#.

Ah I see, and sorry didn’t see the part about C#. Anyway good luck with the project.

Ok, but I already made a QT project for now so I’m going to post it on Dropbox for now. The C# one is for Windows Phone app.
the QT project is in C++.

You could make the launcher start a tiny webserver with the GUI. On a desktop it launches your default browser. On a server you can go to yourserv.er:portnum/ and it’ll also show the GUI (maybe after user pass login).
That way both desktop and server users can benefit from the same code and desktop users can close the GUI without it causing the server to stop.

1 Like

Why on Earth would you run a server from your phone. That would be incredibly slow.

@DarkArcana I think what @NoidEXE Was saying was start it on the server machine, and then connect using any device with something like: 192.168.1.155:80 in a web browser.

Correct me if I’m wrong :stuck_out_tongue:

That’s exactly what I meant. If you’re on a desktop machine you start the GUI and it’ll do xdg-open http://localhost: <port> on Linux or start http://localhost: <port> on Windows right after starting the web service. Once the service is started you can connect from any other device.

The idea is that you don’t have to know how to configure a LAMP, WAMP stack to get a simple, web based GUI that you can access from everywhere.

I think MCMyAdmin works that way. Don’t really no since I just use ssh and tmux.

Why C#? If you have learned it, you can very easily switch to Java and make this platform independent. As Sponge uses Java, other projects related to it should probebly do the same.

Yes, there is Mono for Linux and Mac, but its noy working perfectly if program is specially coded for Windows. And there is Wine, but using it is often pretty complicated.

DarkArcana: Not really, I ran MCServer with Raspberry Pi. :smiley: For some reason they have even released APK for it…

Mono is good enough for such a program :wink:

Not always.