Starting Missions from Linux Builds

[Argh]

Ok, basically I have a simple question:

I want to build a launcher utility, maybe a simple html page, that will launch missions for Linux users of P.U.R.E.

I need to launch Missions this way, because:

A. It's more elegant if I present it that way than tell people "use the lobby".

B. They cannot see the Missions in the Lobby, because the Missions are modtype 0 (to keep things less confusing for end-users).

Soooo... can I launch Linux Spring via some method with the right parameters to allow it to run the mission? And if yes, how?

This is the last major technical area of P.U.R.E.'s Linux launch that I haven't been able to resolve yet, so any answers would be appreciated.

[zwzsg]

Hey Argh, let's unite our voice into asking the ability for widgets and gadgets to relaunch Spring.exe with a given startscript as a paramater so we can have an OS agnostic way to run strings of missions.

[Argh]

Ok. That's one route.

And there's always having a proper front-end built with Lua that loads immediately when you launch Spring manually, instead of a hard-coded system, that could also do... "crazy" stuff, like close Spring and open SpringLobby / TASClient, so that people have multiplayer and single-player in one convenient package.

But... in the meantime... I have had several people asking if they can buy the Linux version of P.U.R.E.... and I have a list of Open Source channels I want to begin talking up the Spring Engine's potential to... and I cannot even show them a credible tech demo that won't get me laughed out of the room, let alone a complete game that actually feels like a polished experience.

Even a simple launcher implemented via HTML or JavaScript would better than nothing. And, since I know zero, zip, nada about Linux... meh, I thought I'd ask if there was some simple way to go about this, and proceed from simple roots to final.

[Pxtl]

I have been working on getting AppLauncher running under Mono, but Mono throws a hissy-fit at simple things like resizing the form. Plus, a lot of Linux geeks are snobbish about Mono.

[Argh]

That would be a major step forwards, indeed. And it would certainly address the immediate need.

But it appears that we should maybe talk about this whole "launch within the engine" stuff s'more, too.

I'll sit down and make a mockup. This is a must-fix area, imo. That Spring launches in a developers-only fashion and lacks certain key things in terms of polish is a major issue that the Linux situation makes me appreciate more.

Pointing people at the Lobbies, which have very complex interfaces (overly complex, imo) is not a solution.

[Pxtl]

I've looked into registering applications for the browser in Linux, and it's even uglier than it is in Windows - there is no unified place to store that setting - different browsers and desktop environments will have different URL handler approaches, if any at all. I mean, you could register Spring as a URL handler in Gnome... but then you're SOL as soon as you get a KDE user.

[quantum]

Maybe this has some reusable code:
http://planet-wars.eu/missioneditor/launcher/

[Argh]

That's definitely a thought, too.

Here's my take on this.

What we need is pretty simple, really. We need to launch multiplayer, the Settings application, Missions (which should be auto-locked to a Map by default) Maps with a given configuration... i.e., everything that's done in a Lobby, but with an interface within the application.

Basically, what I'm doing with AppLauncher, but within Spring itself.

I know there are perfectly-valid reasons for keeping multiplayer separate from the application, and that's just how it goes.

Here's my mockup, showing what I think it should look like, if you just run Spring, replacing the current system:


The dark gray to the right of Games / Maps is a slider. The bright blue would open a drop-down with a slider.

Basically, we'd have a big imagemap as the background, which would change based on the game / mission selected, with some neutral default in /base, if nothing has ever been selected before or the game / mission lacks any reference to the relevant bitmaps.

Elements like the drop-down buttons, the slider background, etc. should just be bitmaps that can be changed out. For even more coolness, we could make a "widescreen" and "standard screen" set of graphics, so that it won't be horribly distorted on either.

I can't say I'm looking forward to the cat-fight that will ensue over making that neutral default, but whatever, that's battle number two, and isn't that important... so long as it isn't mandatory that all games are stuck with it... like Applauncher, basically.

Note that the "launch TASClient" needs to be disabled in Linux. So I'd say that the application should search for the relevant applications, and disable any that aren't present (that would also probably help non-savvy Linux users to know that they haven't compiled something they need, like SpringSettings or SpringLobby).

With Missions... they should be modtype 0, and they probably need a new tag in modinfo identifying them as Missions, not mods / games. And by default, they should be locked to a given map, via another tag, to keep things simpler, since the vast majority of Missions need a specific map to function correctly.

Sooo... other than complex wrinkles, like not allowing Mission X to be played until Mission Y is complete (which is a very big mess) it would be very similar in function to what we do now, manually, with a couple of major differences:

1. It would allow for multiple "players" to be set up.
2. It would respect ModOptions, which would be very nice for testing purposes (running a Lobby just to test that stuff is fail).

If "choose in game" is the option picked for player starts, then bots need to be randomly assigned one of the standard start positions.

[Argh]

Anyhow... I know that's a major feature request, folks.

But it would pretty much fix everything at once. Missions would get tied to map --> modfiles via dependencies --> background template --> UI elements, with neutral defaults

Mods / Games would be tied to --> background template --> UI elements with neutral defaults

Maps would be tied to nothing at all, unless we want to broaden the support for "maps that are really mods in disguise", which is OK with me (it was the reason why most of the WC3 mods exist, after all).

It sounds like I'm hosed just using a web-page or something to handle launches for Linux, though.

[zwzsg]

And there's always having a proper front-end built with Lua that loads immediately when you launch Spring manually, instead of a hard-coded system, that could also do... "crazy" stuff, like close Spring and open SpringLobby / TASClient

I had that done, (though you still had to pick whatever map & startscript before it would appear) but then the security hole I exploited was closed.

[Pxtl]

This is a first working implementation of Applauncher 1.2.3 for Mono. It seems to choke on PDFs, so the earlier-mentioned approach with DoOpen webpages instead of PDFs would be good.

It's just a debug release, but it looks to work well. Compiled with Mono 2.0 (which is not available on Ubuntu 8.04 LTS, the current Long Term Support version, which could be a problem).

If you're going with AppLauncher, you'll want to provide a set of command-line scripts to execute the single-player missions as well, since not everybody will have access to Mono 2.0 sadly. It's ugly, but you'll at least have something to tell the users - "if you want the pretty launcher, you need mono. Otherwise, you'll have to use the batch files".

Still some bugs to work out - no scrollbars yet, for example.

[clericvash]

I hope you can work out something Argh, i'm the one who posted on your forum asking for it :).