Release Early, Release Often.

[hoijui]

+1

[AF]

For lobby compatibility I would suggest the following unitsync callouts to be added as soon as possible even if in the current version they return hard coded values. Adding them now would future proof any clients or libraries that launch spring:

Code: Select all

int GetInstalledEnginesNumber();

returns the number of installed spring engines. For now this would be hard coded to 1

Code: Select all

int GetPreferredEngine();

returns the ID of the 'preferred' engine, default being the latest but changeable via engines.lua in the bin directory when that is implemented. For now this can be hard coded to 1 too.

Code: Select all

const char* GetEngineVersionString(int engine);

This would just return the current spring version unitsync was compiled with for now, but otherwise it would returnt he version string associated with that version of spring specified, the same value used in the uberserver lobby protocol to differentiate engine versions.

Code: Select all

const char* GetEngineBinaryPath(int engine);

This would return the file and path of the spring engine binary associated with that version. Thus a lobby client would start spring by executing the following pseudo code:

Code: Select all

String command = untisync.GetEngineBinaryPath(engineVersionID) + " script.txt";
execute(command);

I would implement this right now but I am at work and the ports for svn are blocked, that and I'm at work so itd be an abuse of resources =p

[Auswaschbar]

Alternative suggestion:
Lets assume / is the directory where spring is installed.

• a subdirectory Releases where each release will get its own subdirectory where the following is stored:
  • binaries, dll's
  • base files (springcontent.sdz) because they are likely to change each release
  • AI-dll's because they only work with the version they are built for
• another subdirectory Data or Content, where all maps, mods, otacontent and stuff goes in

It has the following advantages:

• no source change required, all this can be done without any engine modifications
• adding a new release will be as easy as extracting an archive into the right subdirectory

[Licho]

Atm there is problem with springcontent being hashed .. so different engine versions produce different map hashes..
This should be fixed too before :)

Auswaschbar folder scheme sounds nice.
And we can add simple "loader" named spring.exe to replace current spring.exe -> it would launch correct version based say on parameter or even script tag.
Combined with unitsync providing list of currently installed engines it would provide transparent and easy to use infrastructure for all parts of the system.

[det]

Just version springcontent.sdz, Spring 0.77b3 would load "springcontent-0.77b3.sdz". Then remove it as a dependency for map hashes. This would also solve the problem of users having old versions of springcontent.sdz in their spring directory, on Linux, overriding the correct version.

[AF]

Sounds fine until you analyze potential requirements:

• The assumption that AIs are only compatible with a single release does not hold once the new AI interface is deployed, and instead AIs become more like content.
• You assume all content is compatible regardless of engine version but this is not true. 0.77 broke much lua as did 0.76 and 0.75. The need for a minimum version as a 'system requirement' of game content is necessary.
• I used the name 'bin' rather than releases because this is more familiar to both commercial developers and users. Its best we keep the same naming schema as the rest of the industry rather than needlessly deviating for no reason.
• Your proposal still requires source changes. The current spring engine versions folder requires a higher priority in the VFS than the other folders, and you cant expect linux users to go into their resource file and re-order things whenever they switch versions.
• This switches the onus onto lobby developers to automate the process and would you be happy letting arbitrary tools meddle with your configuration files that are intended to be modified by hand?
• This does not solve the problem of which version of spring to use in the lobby and requires user intervention everytime a new version is released to tell the lobby to use that version in future otherwise once a new version is released existing users will end up hosting games for the previous version not the latest unless they manually correct the issue. People will be p*ssed off.

Regarding otcontent.sdz, this can change, at which point you would need to make the installer insert an otacontent.sdz in the folders for the older versions of spring, and then you've got massive duplication, the installer code becomes a lot more complex and it quickly becomes a nightmare.

Instead, if using my proposed mechanism, otacontent.sdz would take tis place as part of the engine, an optional compatibility layer. It would go in with the engine binaries.

The difference being that unitsync and the VFS would add all the folders from the previous versions of spring installed to the VFS aswel, so that if 10 versions of spring share an otacontent.sdz, only 1 copy of the file is needed. Any new versions of the file will take its place in the VFS.

This also allows much more flexible patching, since dependencies accessed via the VFS for the core engine need only be updated or installed when changed or fi no previous version has the current file available to use.

[BrainDamage]

i am more prone to chose the unitsync solution even tho this makes another problem too, unitsync versions are not retro-compatible (see different hashes or they simply crash if they can't find the appropriate springcontent ), so unitsync would have to be changed so when it inits only loads the bare minimum handlers.
Also needs a call-out to retrieve the unitsync path which belongs to the appropriate version

Code: Select all

const char* GetUnitsyncPath( int engine )

[Tobi]

I don't think adding the task of managing Spring versions to unitsync, which is inherently bound to a specific Spring version (because a huge part of it's code is Spring code), is a really great idea.

It could mean lobby has to operate with 2 different instances of unitsync, the newest one for getting which engines are available and then one other for the engine which is currently enabled. (because who knows what may have changed which somehow breaks the old spring when it gets input (through lobby) from newer unitsync.)

Also it would mean that unitsync itself could not be in this bin/VERSION_STRING/ folder because then the lobby wouldn't be able to load unitsync to figure out where unitsync should be loaded from.

In short, I think it should be a wholly separate tool dedicated to this.

On Windows a DLL seems the most logical choice, while I can imagine on linux a spring-config binary (or shell script even) would be sufficient. (and more consistent with many library packages etc.)

[AF]

I agree

[Licho]

Idea:
2 support libraries for lobbies

1) "springsync" - used for common things - it could provide archive checksum and iterate engines installed

2) multiple "unitsync" - used to do engine specific things, like calculating full mod/map hash, iterating mod options etc. Springsync could optionally take engine version as parameter and relay request through correct unitsync dll

Lobby protocol changes:
- for maps and mods archive checksum will be used instead of mod/map checksum which depend on spring content.

- each battle advertises its engine version, mod and map archive checksums

- when player joins battle room full mod checksum (not archive) can be used to check for sync

[AF]

The existing protocol requirements already exist in uberserver, there's even support for different game engines nm their versions.

[el_matarife]

another subdirectory Data or Content, where all maps, mods, otacontent and stuff goes in

This subdirectory should be moved to the My Documents\My Games or All Users\My Documents\My Games for a variety of reasons including Vista compatibility, compatibility with System Restore and other backup products, and current "Best Practices" on the Windows platform. That directory should include everything that gets written to regularly, so maps, replays/demos, logs, settings (Hopefully in an XML format rather than registry), Lua widgets, etc. In fact, you may want to consider placing all the maps in the /All Users/ folder and everything that's more of a per user file like demos or chat logs into the user's /My Documents/

Of course, all this should be configurable, especially since replacing all the settings with an XML config file plus this new directory structure could allow for a "portable" version of Spring for external drives.

[Tobi]

AFAIK that's already possible, just not configured by default to do so apparently. (There also seems to be a part of the userbase who find it too complex when spring can use more then 1 directory...)

Is all users folder writable for all users?

[AF]

there are callbacks to retrieve the path to the shared directory under windows, which would be best since there is no 'all users' folder in Vista, since that entire component was ripped out and re-implemented (theres no documents & settings folder in Vista, its just a symlink that you cant follow, instead you have a program data folder and Users folder C:\Users\Public).

[el_matarife]

there are callbacks to retrieve the path to the shared directory under windows, which would be best since there is no 'all users' folder in Vista, since that entire component was ripped out and re-implemented (theres no documents & settings folder in Vista, its just a symlink that you cant follow, instead you have a program data folder and Users folder C:\Users\Public).

Excellent point. There's MSDN articles documenting these best practices I linked last time this topic got brought up before it got buried in a variety of weird temper tantrums and tangential debates. Here's probably the best one:
http://msdn.microsoft.com/en-us/library ... S.85).aspx
This is the MSDN article detailing all the current callbacks for these common folders: http://msdn.microsoft.com/en-us/library ... S.85).aspx

Anyway, I think Auswaschbar was already working on these folder issues in June. I am not sure how far he got, since Spring still seems to be using the directories in Program Files rather than something more UAC friendly.

[YokoZar]

Do we really need support for more than two engine versions? There seems to be a lot of potential for overengineering here - all I really need is the "Spring everyone else has" and the "latest Spring that we are going to test on".

[Wisse]

+999

There shouldn't be more than 2 versions at any time. No way you're gonna get more testers on individual version than ur getting now.

[hoijui]

i disagree.

first of, introducing support for unlimited amount of engine versions is most likely not more complicated then support for only two.

second, what about branches? they dont fit into either of your two solutions, and of course they would also profit if it was easy to test them.

[AF]

Were still forgetting keeping old versions so players can play replays still!