i would not like to specify a dll on the comand line, that does not make sense to me. I am also not sure if reading the config file is a good idea... the launcher would have to be as slick as possible. though this is maybe still ok, but a border thing.

it would not be adding a new point of failure, but that point would be shifted from many places (all the lobbies and dedicated hosts) to one place (the launcher). of course, the launcher could go boom, but the way i think of it, it will be so slick that it will be hard to do wrong. it will also be simple, and every one will be able to fix it easily.. and it will be bug free very soon.

what it needs:

• loading shared libraries
• browsing file system

i already have these in two C source files with practically no dependencies under AI/Wrappers/CUtils/, which are used since some time already, and should be relatively bug free, and could be used here after a little refactor.
Alternatively, we could probably even use the sources under rts that solve the same purpose, but maybe we would have more problems with too much dependencies there.

...no mood to line up benefits again now.

Program X needs to find spring -> run spring
Program X needs to find launcher -> run launcher -> launcher needs to find spring -> run spring

I don't see why it would be easier to find the launcher than just find spring directly.

Program X needs to run spring -> search spring -> run spring
Program X needs to run spring-MT -> search spring-MT -> run spring-MT

Program X needs to run spring -> search launcher -> run spring
Program X needs to run spring-MT -(launcher found already)> run spring-MT

as said, the launcher not finding the dlls should not ever be a problem one month after first release of it +

That works I guess. Possibly if you use more than one lobby you will have to change the config in many places which may be inconvenient.

And the launcher will find the MT exe when downloaded from the internet with an arbitrary filename? No!

So there are basically 2 possibilities:
1. Give the exes hardcoded file names so it can find them -> no launcher needed, as this could as well be done in lobbies
2. Make a config file where user can select executable -> no launcher needed, as this can be done in the lobby already

In fact, I think of the lobby already as a launcher. It might not be a perfect one, but you won't solve its problems by putting another launcher in between. Also I think the all-engine-as-dll is stupid, as you can get the same effect by just launching seperate executables (+ its less work).

got ninja edited and I cannot remove this message :/

Auswaschbar not everybody uses a lobby to launch spring, and its much nicer to just specify a version and a type and launch rather than having to use a naming scheme and have hundreds of spring executables.

For example fi we have version numbers in the filename, which spring do we launch? I can imagine in this situation someone would write a tool to help clear it up, so we could always execute latest official release, some sort of launcher....

i indeed did think on hard-coded dll names. and then it would still have the advantage of shifting the possible point of failure from many places (lobbies) to one (launcher). a minor pro is also, that the launcher and the dlls are managed by the same people (engine dev team).
an other pro of the launcher is that we can move the dlls into a sub-dir.
plus the possibility of multiple spring versions through a single executable (usefull for playign demos eg), for which a launcher is a first step towards the Endl├Âsung.

i agree with you, that none of the advantages are really world shifting, but they still are there.

The only point of failure I can see currently is lobby not finding spring, which will then be replaced by lobby not finding executable. Also, Lobby <-> launcher is not less error prone than lobby <-> spring.


I somehow miss how this solves the problem of multiple unitsync versions, multiple basefiles versions and the problem that neither lobbies nor the server are ready / aware of multiple engine versions. These are the _real_ problems with multiple engine versions, not some "oh its all called spring.exe and in the same dir". Also: /usr/games/lib does not need any subdirs...

Oh and nitpicking remark: Endl├Âsung = everyone is dead

that is a very specific interpretation of the word, i am shocked you only got to that.

i was aware of all the other problems you mentioned for multi version support (BD already mentioned them to me).

i quite clearly explained that the lobby will be able to use different springs when knowing the location of a single executable.. you repeat yourself.

And I quite clearly explained that its not that easy. First you need a protocol for communication between launcher and lobby: to query which versions are available, how compatible they are with each other etc.
Secondly, it gets alot more confusing when you take into account that starting spring is not always the same. It changes from time to time, making the launcher useless every time it does.

edit: I don't care if you make a launcher and use it, as long as its use is optional

you seem to be the only one that has objections (taking out those that did not understand the idea), and you know that it is not possible to do optional the way i described it (eg, it would mean having spring.exe plus launcher.exe & spring.dll(containign the same stuff as spring.exe)). all you said only makes sense when extending the launcher from the basic idea, as the basic thing would not need a protocol or anything else to change. when adding MT or dedicated-client support to lobbies, it would just be an other way for the lobby devs to add it, one with more problems shifted to the launcher then wihtout it. if we add more functionality, the lobbies have to change, just about in hte same way they had to change when we added the same functionality in an other way.

when i might compare this to the new built in menu you made, it seems like a similar thing to me. though there was probably not as much discussion about it (the details) as here, you made it, and in the beginning it was less comfortable for me (and others) to test, cause it was buggy and one had to use the mouse to start the preset start game. by now, you made it work as well for testing as it was before.

As the author of one of the major lobby projects this community as seen, I am in support of hoijuis idea