Starting spring from the command line without a setup

[Auswaschbar]

Removing it would make stuff alot easier. So I want you to comment if you use it, and when how you use it.

What I thought of:

• normal way of starting should be with a setupscript (its easy to write on, or copy it)
• only host will need full startscript, it will be transfered to all client after they connected to the server (clients will only need unsynced stuff like myPlayerNum, host and hostPort...)
• a demofile can still be started without a script (it will be read from the file)
• for easy testing things, I would make a default script included with configurable map, mod and script

edit for clarification:
its about removing the possibility to start spring without a startscript (name it script.txt or sumthing)

[zwzsg]

I dunno what you are talking about but I sure hope it's not about removing the script.txt. It's only way I have to directly launch a spring game.

[hoijui]

no zwzsg, don't worry, thats not what he is talking about.

-1
i want it to stay.
for testing, a default script is too much hassle.
for me, working on a branch eg, i would have to use a script all the time then, and manually update it whenever the format of the script changes and i reintegrate the trunk.
actually, its not that i need it to stay as it is, but using a script all the time is too uncomfortable for testing. we would need an other way.
also: using the clients for generating a default script would only work for the current release version, which is hardly ever used when testing.

[zwzsg]

So you mean removing the little mod/script/map menu from inside Spring?

That one?


Well, I could do without it personnaly.

However:
- Make sure Spring then output a newbie-helpful message instead of technical lingo.
- Make sure the official Spring installer from Download page contains a single player lobby.

manually update it whenever the format of the script changes and i reintegrate the trunk.
[...]
using the clients for generating a default script would only work for the current release version, which is hardly ever used when testing.

Lies! I just tried! I took a script.txt lying in my oldest Spring folder, that is 41b1. Dating from may 2005. Then I made it run by 77b5 (oct 2008) The only thing I had to change was:
- Change map extension from sm2 to smf (because map format changed a long time ago)
- Add GameType=XTA_Installer_Version.sdz; (because back in the time Spring didn't handle mods, it merely read taenheter.ccx in the root)

That means you can keep your old scripts forever, the newer Spring.exe version still accepts them.

[Posts]

+1, the lobby clients / autohosts will for ever taint the sync purity with the current system.

myPlayerNum, i'd rather see a large private random number sent through the lobby server(from host to client on battle join)
* lessens damage caused by wrong number (blame can be pinned on a single person / program, and with more certainty)
* lowers risk of lobby client making a mistake
* blocks exploits (pretending to be someone else, connecting to a passworded game, chaos, etc)
* potentially creates new bug: lobby clients give two clients same random number by chance(rare case that may not be checked / checked properly)

[SinbadEV]

I don't understand why the current behavior is a problem... but to be honest it would be better if a good user-friendly single-player front-end was incorporated in the default client.

[FLOZi]

If it's removed, you damn well better make a lightweight app that performs exactly the same way.

[Kloot]

I use scriptless startup all the time when debugging, which can involve
_many_ compile ==> run ==> crash cycles to pinpoint something. For
convenience and productivity I therefore prefer making those cycles as
short as possible, compare:

Code: Select all

'x' <enter> // XTA
'c' <enter> // Commanders
's' <enter> // SmallDivide

which takes less than a second to zip through to having to configure
a script constantly, which would be a _PITA_ for every small change to
that sequence.

TLDR: minus one (Googolplex) to this idea.

[Tobi]

IMO refactor it so the in game menu is just some simple code which generates script.txt internally and passes it to CGameSetup. This would remove all the tight coupling and multiple startup code paths (which are indeed a pain), but would still allow for fast and efficient debugging/testing, etc.

(Of course I agree with Kloot cause I made all the completion stuff in these menus myself, to speed up debugging/testing )

Networking from commandline (e.g. -c -s switches) can be removed.

tl;dr: -1

[AF]

If we can re-implement the startup GUI in a separate program perhaps? Something small we can reuse a lot of code for....

[Kloot]

Actually the CL network switches are still very handy too, I used those
to resolve #1050 for example by running two Spring instances on the
same box (more efficient than starting springlobby twice or writing the
script by hand ).

[Tobi]

If we can re-implement the startup GUI in a separate program perhaps? Something small we can reuse a lot of code for....

Doesn't help for the major reason at least kloot and I want to keep it

I say, just decouple the menus and make them write script.txt in a string and pass this to CGameSetup. No multiple code paths anymore, better maintainability, and no useful features removed.

[FLOZi]

If we can re-implement the startup GUI in a separate program perhaps? Something small we can reuse a lot of code for....

Doesn't help for the major reason at least kloot and I want to keep it

I say, just decouple the menus and make them write script.txt in a string and pass this to CGameSetup. No multiple code paths anymore, better maintainability, and no useful features removed.

A big +1 to this.

[Auswaschbar]

Actually the CL network switches are still very handy too, I used those
to resolve #1050 for example by running two Spring instances on the
same box (more efficient than starting springlobby twice or writing the
script by hand ).

You would only need full 1 script for the host. The client is happy if yu have hostaddress and playernum in it.

[imbaczek]

+1 for Tobi's proposition; -1 otherwise.

[hoijui]

+1 for Tobi's proposition; -1 otherwise.

+1

[Beherith]

If we can re-implement the startup GUI in a separate program perhaps? Something small we can reuse a lot of code for....

Doesn't help for the major reason at least kloot and I want to keep it

I say, just decouple the menus and make them write script.txt in a string and pass this to CGameSetup. No multiple code paths anymore, better maintainability, and no useful features removed.

Would that mean no more menus at start?
I use them very often for map testing.

[hoijui]

as i understood tobis idea, the menus would still be incorporated into spring.exe, but internally they would be decoupled totally (the menu code would write script.txt, and hten start an other part of itsself (the real game) with that script. so in fact, a built in single player lobby or something like that.

[Tobi]

Yes, for end user nothing would change, only code would be much more maintainable because of less possible code paths.

[Tobi]

BrainDamage pointed out that for this to work Spring probably would have to send the generated script.txt over the network.

This would give opportunity to also do this for normal games, except for the few variables that must differ per player.

The advantage is that then lobbies don't need to sync 100%, since what the host lobby thinks the settings are, will get used. Lobby clients that only joined battle wouldn't need to write more in script then HostIP, HostPort, and MyPlayerNum (or name, for more robustness wrt player/team/allyteam reordering?)