Spring RTS Engine

The SpringData dir should be used to listen to what the user wants, not telling him what the lobby wants. I already stopped using weblobby because of this, because each time I use it I have to go back and reconfigure my SpringData dir variable to read from multiple places.

Obvious mega fix for that: copy your SpringData string into weblobby's Settings -> Spring Home.

There are exactly three mentions of SpringData in SWL source:

~/Programs/qtswl$ grep --exclude-dir="*.svn" -sirn "springdata" ./
./site/lwidgets/SpringSettings.js:259: 'SpringData',
./site/lwidgets/Lobby.js:289: this.getUnitsync(version).setSpringConfigString('SpringData', this.springHome );
./site/lwidgets/Lobby.js:547: this.unitSyncs[version].setSpringConfigString('SpringData', this.springHome );

-> SpringData is set by weblobby verbatim from your springHome setting.

And i think this is exactly how it should be between lobby and engine.

Multi-lobby single-engine installs are probably something only a spring developer should have in the future where games go on Steam and package themselves.

Anarchid wrote:Obvious mega fix for that: copy your SpringData string into weblobby's Settings -> Spring Home.

imo thats the correct way how to implement it on lobby side, springlobby doesn't do this yet, but it would be a trivial change atm.

It should be the other way around: it should read that from the setting, not write it.

Jools wrote:It should be the other way around: it should read that from the setting, not write it.

thats not possible if no spring is installed. also if multiple versions are installed, what if there is a discrepance?

-> no

also loading unitsync can take ages, this heavily slows down start of lobby. spring doesn't know about other installed engine versions, only lobby does!

It should be the other way around: it should read that from the setting, not write it.

The SpringData dir should be used to listen to what the user wants

Those points contradict each other.

Now, before you say i've ripped your quote out of context: which do you think the user will likely use to speciy their desires:
1) an obscure config file
2) a setting in lobby

Hint: in year 2014?
Hint2: player, not developer?

Anarchid wrote:
Now, before you say i've ripped your quote out of context: which do you think the user will likely use to speciy their desires:
1) an obscure config file
2) a setting in lobby

1) is not an obscure config file: it's the one reached from menu when starting spring.exe, and it's the one you always know is the correct one that the engine reads. There can be many lobbies who all use different config files.

2) There are many lobbbies, they can be used simultaneously, they all have different logic.

Jools wrote:1) is not an obscure config file: it's the one reached from menu when starting spring.exe, and it's the one you always know is the correct one that the engine reads. There can be many lobbies who all use different config files.

thats some "advanced settings menu". mostly no need to use it.

Jools wrote:2) There are many lobbbies, they can be used simultaneously, they all have different logic.

use a symlink then! or configure each lobby! no player uses multiple lobbies, that makes very few sense. you suggest that spring configures lobbies.

you are doing it wrong, don't expect to work stuff when doing weird stuff.

(unsuscribed from this topic)

Symlinking works if you assume users always have one boot drive...

... but for those who dual boot, the "my documents" folder is dependent on which drive you boot from. Those users may not wish to duplicate the spring data on each boot drive. My spring data folder is about 15 Gb. Yuck.

iam a player and i try to use different springlobby´s.

its annoying to make for every engine version, game, videorecording, benchmark a new setup. iam also mostly ati user and each game have different gfx issues on it.

there should be a easy way for users to handle it, springlobby is in fact no steam/web/specific game application, its a multiplattform for different games/mods and used by rookies/veterans and developers. a feature like this cant be that bad. the current way is too complex