The idea:
instead of spring.exe, we would have launcher.exe (could also be spring.exe still, but i will call it launcher.exe here, cause its easier to understand this way). spring.exe would then be spring.dll, and would be moved to a subdir (eg lib), together with all the other dlls. the lib dir would also contain spring-dedicated.dll, spring-headless.dll, and spring-dedicated-client.dll. The launcher could then be called in these ways:


Pros:

• dlls would not have to remain in the main directory
• only one exe in the main dir
• in a lobby, you would have to configure the path to launcher.exe only, and all the versions could be used then, without changing the configuration. for example, htere could be an additional check-box right next to the spectator box, labeled only record demo
• possibly other things (eg. run headless spring by default on linux, if no X is available)

That would make this launcher mandatory tho, right? At least on win where people would have a hard time running a dll type file (even if it isn't really?)

would be awesome, can we specify a different start script dir and bg image for what would normally be the spring.exe menu? that would be pretty cool if all I needed to do was run a bat to gundam-ify spring.

if it would require a lobby to run I am 100% against it. Spring.exe is one of the fastest ways to test for me.

DLL are compiled code that can be loaded dynamically by executing code.

I can give you that already, just go steal kp_spring_direct_launch.lua.



But hoijui idea is different. He basically just want to ship installers with the dedicated, headless, only-record-demo, and normal version of Spring in a subdirectory.

damn so if you delete the launcher you won't be able to run spring ??

dun wry I'll maek yuo another luancher tehn

I had no idea.

Sure they are, double clicking them still won't do, even if they're not really dll but renamed exe.

I like this idea because the launcher would simplify running different spring versions alongside, such as MT or possibly binaries optimized for different platforms. By default spring should then only ship with the launcher imo, and the user downloads the binaries somehow.

+1

Its obvious you guys havent actually looked at what hoijui posted

replace all mentions of:



with:



Hey presto done. Everything works the same.

The only difference is that launcher.exe does not contain the code to run the game, the code to run the game is inside the dll files, and is loaded at runtime.

DLLs are not programs. They are libraries, just like lib files, only they're not compiled into the program at the linker stage, they're like .dylib or .so AIs are right now.

Just imagine taking KAIK or NTai and changing the file extension to .exe, it will never work, its totally illogical, and its the same here. The dlls would be an implementation detail.


Why anybody outside of development need post in this thread is beyond me as it changes nothing for content developers and average users at all.

the launcher could be named spring.exe, and double clicking it would result in the exact same happening like double clicking spring.exe now. lobbies would not need to be changed at all after this change.
the only thing that would not be possible anymore is double clicking spring-dedicated.exe, spring-headless.exe or spring-dedicated-client.exe, but one had to start them through launcher.exe/spring.exe with the appropriate option (eg --headless). I hardly see this as a bad thing though, as it possibly can even help preventing confusion ("why do i only get a black window when starting the game? (double clicked on spring-headless.exe)").
I don't know how springie and spads work, whether they use the dll already, or rely on spring-dedicated.exe. They would need a change most likely, which would be about this:


@smoth
this would be a very low-level/basic change, and does not at all touch something like the ingame menu. also, i never heard of anything like the start script dir, as you should allways give the full path to the start script, and it does not matter where the script lies.

@zerver
totally forgot about MT version! yeah would be nice for that too, also there, we could make it use MT version by default on systems with certain specs (eg more then 1 core), if that is considered stable enough. (which as i got it, mainly depends on the widgets used though :/ )

launcher would be mandatory of course, think of it as the new spring.exe. its just that it relies on more dlls then (eg 24, instead of 20).

I did not yet think much about which parts should come with the installer, and if we should build in a downloader into the launcher to download the other parts when needed/requested, but these are things that get possible then.

edit: self-zenzoring

I would suggest changing the filename to engine.exe

edit: springengine.exe? so as not to cause confusion under nonwindows systems, we can already change the name in the springlobby settings so the migration is quick and easy

Instead of running them via parameters ("-- something"), include the option in the startup UI. If we're going to start distributing all of the sub-versions of the engine, make them all accessible from a central place to end-users. It seems like it would cause endless confusion if it's based on parameters, tbh, because it may or may not work correctly in all environments, and then we'll have yet-another sticky explaining to poor end-users why "Spring does nothing". The engine should do that part, based on what OS we're running.

That's silly because any use of nonfull UI spring will be by someone who knows enough to do a commandline parameter, or by a tool that is written by a programmer who will know about this

MT?

And... what about autohosting with headless?

+1, don't make a launcher please !! plus as koshi said you couldn't launch the dll directly !

My comment was not meant to be pro or contra launcher. Actually, as I said in #sy the other day, I think a launcher that is transparent to usage as normal spring.exe is not a bad idea at all.

Satirik that is not true at all, just add the right commandline parameter! An end user has no use for launching a headless spring.exe or a dedicated host without passing a script as it is.