Planning for 0.77 Release

[Kloot]

R6243 appears to break build-menu orders (start up XTA / PURE / etc,
build a factory, then queue some tanks with and without holding shift)
and the icon count indicators with it, better hold those presses a while
longer.

[Argh]

The Installer does not include a corrected SpringSettings. The TASClient does not properly read the new Registry entries, regardless of how they're set up.

Basically, Spring's completely unplayable through a Lobby client right now, at a practical level.

The main executable works fine, run directly, but it's a mess, and I can't start MP testing with it like this

[koshi]

From what i get this is a unitsync issue, since SpringSettings never touches settings directly, but thru unitsync.
Imo the problem is that Unitsync built with scons already uses the new WinFileSystemHandler (aka the unix one) while the ConfigHandler that the engine talks to directly is still using the RegHandler. This results in two totally seperate sets of settings.

[Kloot]

The filesystem handlers have nothing to do with it, the unitsync
library and the engine just use the same config handler (so if a
lobby loads an old unitsync build with the old CH class compiled
into it then the {Get, Set}SpringConfig* API functions will return
values from or write them to a location that isn't read by Spring
anymore).

[koshi]

well, then the unitsync in whatever installer argh uses must be old, becasue i made him check what unitsync springlobby (and therefore the included springsettings) loads and it was the one from the svn installer. However values were not read from the regtree that engine created when first run.

[Kloot]

Spring executables (and unitsync libs) packed in SVN installers that
were generated from trunk/ will read from "blabla\SJ\Spring 0.76b1+",
the version string hasn't been bumped up there yet. If the installer is
is based on 0.77-branch/ then they get their values from another loc,
"blabla\SJ\Spring 0.77a1". Could be he has a unitsync from one and a
Spring binary from the other, otherwise I don't know.

[Argh]

I've just deleted everything in my SVN install directory. SpringSettings is still reading the wrong (old) values. When launched from TASClient, Spring is definitely using all of the old values, and is borked.

It's not as simple as just wiping out the build, unfortunately. The UnitSync.dll in the current test installer must be wrong, according to what you're saying.

[EDIT]Hold up, I see we have a new installer available... more after I've tested with that.[/EDIT]

[Auswaschbar]

New version: http://planetspring.free.fr/spring/inst ... 0.77a1.exe

I don't know if this has caused the bug, but in the previous version the installer was still set to 0.76b1, which I now bumped to 0.77a1 to match spring's internal version number.

[Argh]

Just tested that, and it's not working, same problems. Lemme wipe the Registry, see what happens when the executable is started, then see what happens with SpringSettings.

[ZellSF]

Will Spring 0.77b1 be multithreaded outside of pathing?

[Argh]

Just tested, after Registry wipe. SpringSettings is writing to /spring Registry tree, but Spring executable, on first run, wrote to /Spring 0.77a1.

[koshi]

another guess:
when compiling unitsync, could it be that VERSION_STRING is not set correctly?

from rts/System/Platform/ConfigHandler.cpp:

Code: Select all

configSource = "Software\\SJ\\Spring " + std::string(VERSION_STRING);

[Auswaschbar]

another guess:
when compiling unitsync, could it be that VERSION_STRING is not set correctly?

from rts/System/Platform/ConfigHandler.cpp:

Code: Select all

configSource = "Software\\SJ\\Spring " + std::string(VERSION_STRING);

VERSION_STRING is not a preprocessor definition:

const char* const VERSION_STRING = "0.77a1";

[Kloot]

SpringSettings is writing to /spring Registry tree

That's the old-old location used by 76b1 judging from the lowercase
's', you wouldn't happen to be running SpringSettings in such a way
that it loads the 76b1 unitsync would you?

[Argh]

I just ran it from the Spring installation directory, same as I always have. I guess I could delete the old Spring... but meh, I shouldn't have to ask beta-testers to wipe out their Spring installs...

[Argh]

OMG... Kloot's right. I just renamed the old 0.76b1 UnitSync... and voila, all of a sudden SpringSettings couldn't find UnitSync and wanted a correct directory... after fixing it, SpringSettings sees the correct values. Lemme test in MP... at least this could be a quick fix, and let me finally get started beta-testing...

[EDIT]Ok, it all works. I'll post that to beta-testers, see if we can't finally have MP games of P.U.R.E.[/EDIT]

[koshi]

i'll have quick hack up in a few min that will always show a panel to set the correct unitsync location on SpringSettings startup.

edit:
here it is http://www.springlobby.info/temp/builds ... 7-hack.exe

[Patch]

New version: http://planetspring.free.fr/spring/inst ... 0.77a1.exe

I tryed this version, and get the same crash. (infolog uploaded) Last post 76b1 version witch was good on my computer, is the last Imbaczhek's experimental bugfix release. http://www.darkstars.co.uk/downloads/vi ... cb4258.zip
(tried on fresh installed windows xp SP3)


But the more important problem is some graphic error with the textures, see what is see. When i zoomclose to the ground, the textures come back to normal. http://img399.imageshack.us/img399/4522/springyp8.jpg
graf: Ati HD2600Pro

[imbaczek]

I've got that graphics bug on a Radeon 4850. No freakin idea how to debug that, any GL-fu hints?

[jK]

try UsePBO=0