Project 10 in 2010 Brainstorming

[Auswaschbar]

I'm reaching out to Sefidel to ask him to knock out a quick .NET application to do keybinds and selection editing. I think it should be integrated in the lobby or somewhat standalone like the settings++ is right now.

TO be really useful, it has to be cross-platform. .NET is not cross-platform.

[imbaczek]

Actually, .NET is good enough as a cross-platform tool, provided you use cross-platform libraries such as Gtk#. Using WPF is a no-no and Windows.Forms may run into issues.

[Licho]

.NET is reasonably crossplatform.

Winter lobby we are developing is .NET + GTK# and is working fine on linux.

Also planetwars and downloader server are .NET applications and were hosted on debian for long time.

If you take some precautions its as multiplatform as java - with binary compatibility.
With even easier multiplatform bindings to native libs than java allows.

[AF]

Winter lobby?

[el_matarife]

The current keybind / selection application appears to be just a standard Win32 application so unless it works in WINE I'm not really talking about a step backward in cross platform compatibility. This is just a small quick and dirty application, ideally it would be implemented in Settings++ or the lobbies themselves eventually.

[Argh]

While that may be an OK interim step, ideally it'd be part of an engine-side front end, like what auswaschbar is proposing. There is no need for separate Settings / Keybind applications at all, and if this was implemented in Lua, it'd be a lot more practical for game designers to customize the UI to fit their needs, which may include radically different keybind setups, etc., for totally different play styles, such as arcade-like controls.

Basically, if somebody is actually willing to make it happen in the engine and make it flexible enough to be useful, then why waste time on other solutions? I'd be thrilled if I could put an icon on people's desktops, have them start P.U.R.E., and have all of their choices right there.

One idea... to keep things easier on developers...

For buttons, if a custom Lua command is going to be run, say "set engineVar to whatever", just allow that as a parameter of a Button. So you just hit a button / checkbox / combobox, and voila.

Only tricky bit is updating the states of the other buttons that would be involved. I think that can just be a simple true / false, or in the case of a comboBox / slider just send a numerical number indicating which position it's at, since they're usually the same thing logically.

I'll spend the time to build Settings, if it gets that far.

With keybinds, it could be as simple as showing a list of the available Commands, and swapping to a new "room" if people have non-American keyboards. I'd need the keyboard layouts / symbols / values (which I'm sure I can look up), but I'm willing to do the grind-work on that.

[Licho]

Afaik you can customize most directly from ingame - from lua.
Check CA interface widget or crude menu. Just some things need restart (resolution).

You could probably edit bindings too. Only problem is stuff like lups.cfg, but again that can be changed in lups itself.

[Argh]

Afaik you can customize most directly from ingame - from lua.

I know that. I have a really crude Settings application in P.U.R.E.

But players should not have to re-adjust stuff like that in-game, imo, and the existing menagerie of external applications to do this is a bad joke.

You have to deal with new players, who are used to opening an application and that's all there, in one place. I do a crude version of this via AppLauncher, but it's not nearly polished enough.

We need the classical, "hit ESC and you're looking at settings and can quit this game, launch a new one etc." behaviors, basically. Just about every player of PC games is very familiar with this UI pattern, and Spring should adhere to industry patterns like these, if we're serious about the goals of mass adoption. The professionals don't use 50 radically-different UI schemas- they're quite conservative in this area of design.

The reason why is because players get annoyed immediately, if they can't figure out how to set their screen resolution, etc. within the first 10 minutes of operating a game.

[Auswaschbar]

While that may be an OK interim step, ideally it'd be part of an engine-side front end, like what auswaschbar has implemented

[Argh]

So, I can test this? Great, I'll go look at it now!

[Auswaschbar]

http://planetspring.free.fr/spring/exec ... 8c874b.zip
Its exe-only, you need to put that into a halfway recent install of the development version.

[Argh]

Tested. Locks up the mouse in the center of the screen when it exits, otherwise it seems to work.

[SeanHeron]

Hey, the download seems to have run out - argh or Auswaschbar, might you reupload? I'd be very interested in testing this (and not too keen on building it from source...), as it looks really promising!

Edit: ignore that, just saw it's in the latest buildserv! Awesomeness! (people wanting to try: in the Spring Lobby, connect to the channel #buildserv, and then download and install the full installation, and run the spring.exe - voila! )

[Jazcash]

Then God clicked his fingers and Winter, Imperial Winter and Uberserver were all released at the same time.