Amazing request!!!!!!11 A must see!

[zwzsg]

Well, last time I tried the portable build of a test version, which was the one newsied on frontpage, it made my regular spring crash (because of the font file changed issue). So Pxtl has a point.

[lurker]

Spring has only defaulted to a local config file for a couple days, assuming that code got finished. I think what you tried was portable-if-you-use-springlobby-to-run-spring.

[BrainDamage]

Spring has only defaulted to a local config file for a couple days, assuming that code got finished. I think what you tried was portable-if-you-use-springlobby-to-run-spring.

or rather, he launched spring directly without using the lobby, and spring defaulted to the normal config file, screwing it up

[zwzsg]

Yes.

I'm kinda curious about how does SpringLobby tells Spring to use another config.

[lurker]

Why reword it in a way that doesn't make it clear that that spring was not portable?

[zwzsg]

The answer is in the question.

The implied message of Braindamage is that passing through SpringLobby should be the one and only allowed way to run Spring. Now that AFLobby and TASClient have been got rid of, he's going for Spring.exe itself! And I'm not even mentionning how 79 removing "package" broke my lua ingame single player launcher.

[Tobi]

This is a configuration issue. If you want people to test, you _need_ to provide a good solution for running Spring Stable and Spring Unstable side-by-side on the same machine. Right now it's too much of a headache to figure out.

On the download page we need 2 installers that create 2 folders and 2 launch-list entries. Spring, and Spring Unstable.

That's what we had in the past but no one used it to test unless I _dragged_ them into the test games.

[knorke]

i tried testversions in the past but i dont like how this can mess up your just-play-online-version.

for example the last patch: springlobby didnt work because it was "missing unitsync.dll" (or some other file, iam not sure)
I go to options to set the correct file path and what do i see:
"e:\games\PURE\" or something like that.

Its been months since i tried pure and of course the folder didnt exist anywmore. wtf!

Iam dont know what files gets updated, but if its only few files or only spring.exe wouldnt it be possible to have spring78:2.exe, spring79_.exe in one folder?

Starcraft does that afaik, this way you can also view replays from old versions of the game.
Or at least have all config files stay in the gamefolder.

[Argh]

Here is a fairly straightforward solution to this stuff:

1. Make the main server act like the Test Server- i.e., do not reject newer / older versions of Spring anymore.

2. Change SpringLobby to evaluate the version strings of players' builds of Spring, and politely inform them if they're not going to be able to sync with other players ("player A has a newer version of the Spring Engine! Update Spring if you wish to play with him!") and do not allow them to launch games.

3. Release more often, and let players do your QA for you, instead of catastrophic levels of change that can annoy large swaths of the playerbase.

4. Make sure that the latest build of Spring Portable (now that that's evolving in a way that better-facilitates these sorts of improvements) is readily available to end-users. Preferably with a nice shiny "update Spring Engine to current version!" button on the front of the SpringLobby UI.

IOW... put the players of free games (and for that matter, commercial games, if they don't want to run their own server), who are using your time and your resources, to work testing your software and letting you know when there are serious bugs.

Make older known-stable versions available as well, preferably from a simple menu, so that if people with Hardware X can't play the current, they can go install Build Y and play with others with the same issues.

It won't make everybody happy. In a perfect world, everybody would get a perfect, bug-free install every update, QA'd beyond any issues.

However, that's never going to happen. So release early, release often, and even release stuff that's potentially unstable in various ways. OK, try not to do that... but it's a hazard that's acceptable, imo. Because then people could "roll back" their installs to the previous stable, and voila, their game works again. Instead of being forced out of online play entirely.

But instead of hoping for an improvement of private QA... let the players do the QA, find your bugs, and report them, preferably without ever having to leave SpringLobby. SpringLobby could even ship you their Infologs with any bug reports, and format their reports to go into your bug-tracker, using a form.

I think this really needs to be done. It'll be less stressful for the developers, if they don't have to do all of the QA on their own, and it'll be better for players in the end.

More time can be effectively allocated on bug-fixes, because developers will have the information they need to fix them and issue a new build via the buildbot instead of doing a long, complex and messy cutoff date for new features, QA period that eats developer time, and then a final build process. Having been through all of this on my end, it makes a lot of sense to do things this way.

Customers of free, Open Source software should expect to be involved with your QA process, and tolerate change. They should not expect a free lunch. Users of Firefox send in bug reports when the application crashes... why shouldn't Spring users be expected to do the same thing?

So... imo, the current process is just being unkind to yourselves and is fundamentally inefficient. I know, from watching what happened in Git, that you folks on the dev side tried your best to QA this release. Spawn_Retard would have been a lot more polite about it, if he'd spent even a minute reading your changelogs on that end. It wasn't like they didn't try, man.

It was just that, like the last ones, it contained so many huge, sweeping changes to so much source that it was a superhuman workload. So... spread it around. Release more often, and find and kill bugs as they come up.

You wanna know the best part of all? If you start breaking backwards compatibility in major ways... all the old stuff is still playable, if people can download the older versions of Spring that still work with Mod X on Build Y. Not that I'm a big fan of breaking that stuff, mind ye- backwards compatibility is an important thing. But you could put yourselves in a position where it's not a vital thing, if you weren't locked to the current concept of a "stable" that may last anywhere from months to a year.

[Gota]

No.
What argh said but only make it so that u can host latest spring in the lobby with everyone from a certain decided upon period to start bugtesting.
High rates of constant updates will fail hard.

[Pxtl]

@Argh - considering how messy the lobby is, and how different versions require different start-scripts (and thus different lobby-supports), I don't think one lobby that supports multiple versions of Spring is feasible.

Really, I think 2 complete installers into 2 completely seperate folders is the only way to go.

[Argh]

considering how messy the lobby is, and how different versions require different start-scripts (and thus different lobby-supports), I don't think one lobby that supports multiple versions of Spring is feasible.

That's now... I'm talking about the future here. To reach that future, it's going to be necessary to get the Lobby to the point where it's able to deliver these things to end-users, and that presumes that where things like start-scripts are... becomes stable soon. I'm really assuming that this latest change is the last one, frankly.

[Gota]

By the way...pure gonna be played in spring when its commercially relased?i mean on the same servers?cause that would own!!

[Argh]

No. We're moving to a completely independent server this week, in anticipation of the second demo release.

[Gota]

Can i log into it with tasclient?

[REVENGE]

Stability is for noobs, betatesting is for faggots.