MineOS-node development is speeding along and some of the more pressing features that the web-ui has remaining (but has been put off till late) are profiles.
Profiles weren’t very intuitive (aren’t?) – or at least people didn’t understand them as clearly as I did (as the designer) – and I would like to fix this going forward.
I have a nice system right now where installing a profile should be as simple as identifying a server version from a source, such as 1.8.4 from Mojang Official Jars, and it seems to work out quite nicely.
I’d like to extend this to FTB, Spigot, Sponge, Forge–everything that is out there. The one thing I need, however, is a reliable way to get the URLs that isn’t parsing HTML (so hopefully RSS, txt, etc.).
The pattern is super easy to see in how they constructed their URLs and perhaps other server mods/packs do this as well? If so, please let me know any insights you have on how I can make it so “create profile” is a thing of the past, and this web-ui can be even more straightforward!
This is precisely what I needed. In response to having an externally-updated list as well as the structure of the URL, I was able to implement all the FTB packs into the web-ui. This means that all FTB and official mojang jars now work out of the box with just a simple dropdown.
http://ftb.cursecdn.com/FTB2/static/thirdparty.xml
Will also give you the information on third party packs in the FTB
launcher.
The difference being whether they were developed in-house or are just
being offered up by the launcher.
This one only “kinda” works. I think I’ll leave this one out for now, for two reasons:
it’s still alpha–there’s no stable, which isn’t so much of a problem, but
an admin will have no real good reason to choose anything but the most recent one, I’d venture.
Hopefully by the time they hit a release candidate they’ll also have an xml/rss/json feed to work with, rather than me have to parse the HTML (which is always pretty iffy).
Instead of parsing html, since the repo is in maven, why not just phrase the way the builds are named by the file . It’s really simple, the target version of minecraft is the first identifier in the version string, followed by the forge version (build) then the API version. It’d be trivial to parse.
Too many options, too many profiles, and too many opinions… And trust me, I struggled with profiles, so having a nice tidy way to deal with them would be ideal, but where do you draw the line? And how many will I have to sift through to find the 2 which I’m actually interested in as a DIY server host?
For instance, you’ve talked about vanilla, ftb, spigot, sponge… What about ATL Launcher servers? What about glowstone and the numerous bukkit replacements? Now multiply that by the number of versions. And again by the number modpacks… The number of profiles becomes mind boggling. I don’t want to store all that on my intentionally small footprint FreeBSD machine.
Honestly, now that I understand the use of profiles, and especially the unmanaged and archive options, a clearer user guide on how to properly use them would be how I’d address the issue. I tweak almost every single modpack anyway, so would end up not being able to download the packs directly, anyhow.
I draw the line at all of em. Literally all of them I can that don’t require such arbitrary setup and config that it wouldn’t work without a tutorial in the end anyway.
With email, you typically have far more in your inbox than you ever will care to reread. And just like emails, the way to make an unmanageable list manage-able is to have sorting, filtering, and searching, which is what is implemented in the new webui, as well.
This is the issue associated with us that i am unable to get the full detail of server paid versions, Fix Error code 0X0070002 helped m eto select the server for my scripting language so far.