hello?

@Argh
i see no even partly valid argument there, plus a few errors:
the ingame menu is part of spring.exe/dll and spring-MT.exe|dll. for it to appear in the launcher, the launcher would have to consist of half of spring.exe already, plus it would not make sense for headless, dedicated and dedicated-client (selecting headless spring in a GUI, hae? )

btw, if there would be a real need for double clicking spring-headless.exe or dedicated or any of the others, then we could still bake a shell or batch script, or even an exe that sptarts "spring.exe --headless", even that this would be really silly, and i can not see any valid scenario for it, except maybe for MT.

yeah but nobody want spring not being launchable without a lobby !

Im sorry but those people opposing this have obviously not read what hoijui is posting and are just reacting to the thread title.

Satirik, that you a lobby developer of all people should be saying the things your saying is a testament to how laughable your posts are. How any of you arent utterly embarassed by how blatantly obvious it is you have no idea what your even responding to is beyond me

I still want an answer to this... before sinbad apparently thought I failed at understanding dll.

@smoth

ok i may not have said that clearly enough, but the bg image resuest has absolutely nothing to do with a launcher as proposed here, please open a new thread or bump a relevant old one or whatever.
and for the start script dir (even doh i still don't know what it should be), i am 99% sure that the same applies like what i said about the bg image.

I know, but I was asking specifically about the spring solution as it would be multi-platform.

My solution is multiplateform.

cool.

Can I port my single player system to Gundam (Saving and loading game state to and from startscript + a regenerative AI that handle any mod + main menu widget + bunch of missions), or would you ignore it if I did?

no sure, go ahead, I would like to see how it works.

if each engine version was stored as a different DLL/SO
then you (or the lobby) could select the appropriate one to run, would be nice.

um.. right... this could probably make running different spring versions from a single executable possible too, eg. if you have the dll for each one of them still around...
it would need some other changes too though, but this would be one step closer to this.

Good thing is that the default exe version to use could be read from springsettings, but also overridden with the command line as suggested.

//springsettings.cfg
GameDLL=spring.dll

// cmd
spring.exe --gamedll=spring.dll

I really don't see any benefits here. Dedicated, headless and main spring exe have totally different use cases, and I don't see why an autohost or a lobby would need to share the same file to execute. Instead of differencing them by filenames, you would do it by commandline arguments, introducing another possible point of failure.

A sane interface to launch different engine versions would be big advantage imo. Not only would it make watching replays much more convenient, it could also facilitate testing of pre-releases.

Indeed, the benefit is that you can set it up to launch a different spring version via the config file, without making any changes to the lobby or replacing the main executable.

Why would editing the launcher config file be easier than editing the lobby config file?