Installer Direction

[Forboding Angel]

/me points at the evo installer

I get it!!!

*raises hand and jumps up and down excitedly*

[Argh]

Well, sure, all the "indies" get it.

But there are a lot of remaining issues:

1. Spring and associated programs need to quit using the Registry at all. Use text files in the root install directory. Keep it all portable, and don't screw up multiple installations of the engine.

2. SpringLobby et al need to quit asking where unitsync.dll is. It's where they're installed. Period.

3. The game servers need to be version-blind. Various versions of the Spring Engine should all be able to log into the servers, and allow people to play (with other people using the same engine build, obviously- probably auto-filtering on the Lobby side would be best).

4. If two Spring Engine versions are the same, but other core files have been altered, such as the fragment programs, then they should be marked as desynced with others online immediately. One of the few reasons I haven't messed with this fundamental stuff is because I know it would cause a disaster for end-users.

5. It might be best, in the long run, for maps to get installed to a common directory for multiple installs of Spring. No need to replicate multiple gigs of maps for multiple games, then.

The first four things would help with the "it's your responsibility" goal here. The fifth would encourage more deliberate Balkanization of game installs... which I think that the engine's finally mature enough to deal with.

I'd really prefer a world where people all installed each Spring Engine game as a separate game, basically. Steps that make it easier for this to be done, on a practical level, where game developers may disappear or update their projects infrequently, etc., would be best.

[imbaczek]

1. Spring and associated programs need to quit using the Registry at all. Use text files in the root install directory. Keep it all portable, and don't screw up multiple installations of the engine.

won't happen, it's against MS software guidelines. configuration is stored in a text file in Local Settings/App Data, every user has his own.

2. SpringLobby et al need to quit asking where unitsync.dll is. It's where they're installed. Period.

+1, but leave the option to change it.

3. The game servers need to be version-blind. Various versions of the Spring Engine should all be able to log into the servers, and allow people to play (with other people using the same engine build, obviously- probably auto-filtering on the Lobby side would be best).

uberserver... aegis whar art thou! (OTOH we already have SpadsGit, so it's kinda possible, just not exactly the right way to do it.)

4. If two Spring Engine versions are the same, but other core files have been altered, such as the fragment programs, then they should be marked as desynced with others online immediately. One of the few reasons I haven't messed with this fundamental stuff is because I know it would cause a disaster for end-users.

this kinda exists, not sure what you mean exactly. base file changes will show a desync in the battle room.

5. It might be best, in the long run, for maps to get installed to a common directory for multiple installs of Spring. No need to replicate multiple gigs of maps for multiple games, then.

already possible. put your maps in My Documents/Spring/maps. works for mods, too.

I'd really prefer a world where people all installed each Spring Engine game as a separate game, basically. Steps that make it easier for this to be done, on a practical level, where game developers may disappear or update their projects infrequently, etc., would be best.

requires lobby/launcher support more than anything else, spring is already quite portable and the next version with fixed command line support (so multiple config files actually work) will be even better.

[hoijui]

1. Spring and associated programs need to quit using the Registry at all. Use text files in the root install directory. Keep it all portable, and don't screw up multiple installations of the engine.

won't happen, it's against MS software guidelines. configuration is stored in a text file in Local Settings/App Data, every user has his own.

????
you mean some devs that code stuff for spring would rather stick to MS guidelines then to what is good for the rping community??
BURN EM!

no really, i do not get that.

[Argh]

uberserver... aegis whar art thou!

Sigh.

base file changes will show a desync in the battle room.

They need to just not see each other at all, imo.

already possible. put your maps in My Documents/Spring/maps. works for mods, too.

Oh. Didn't know that.

requires lobby/launcher support more than anything else

Yeah, that's why I'm mainly focused on that.

It's a huge problem for serious game development. What if you guys release Spring 0.8 this weekend, for example, and totally hose the launch of P.U.R.E.?

Yes, I've sent Auswaschbar a PM about this already. I know you folks are close to 0.8. Hoping to make that part of my first big update cycle for P.U.R.E., if possible.

But basically... this really points out what a huge problem this is. You can't screw up people's release cycles and force them to update their installers whenever the project feels like releasing something. If the number of game developers starts to grow (which I hope will happen) then this becomes a bigger and bigger issue, frankly. I mean... while there are just a few projects, fine, we can talk to you guys and ask for delays and coordination. But if there are 50... well, that's impossible.

So solving the version issue is a major thing, imo, and should be a very high priority.

won't happen, it's against MS software guidelines

The config file instead of Registry entries is not too big of a deal, I guess. I'm really questioning why following Microsoft's standards is such a big deal, though, when it means multiple engine installs could possibly cause serious conflicts between different versions of the engine... because one supports config variable A, and the other one supports ABC... or in one A can be a float, in another only a boolean or integer... this seems fairly dangerous, in terms of true portability.

That... and how can any application claim to be "portable" when you cannot run it from a thumbdrive? That's where I'd set the target, imo.

Screw Microsoft's standards, which aren't Linux's standards and are in fact standards that were suddenly handed down from On High with Vista to make their DRM concept work better, and have turned my My Documents folder in XP into a mess of crap that never seems to get uninstalled correctly, to boot. Sorry, if that sounds strident, but meh. Well-designed applications should all be in one folder, imo. I hate it when they're spread all over your OS and harddrive. Plus it makes it really quite possible that in the future, we'll have entire games made with Spring that quit being actively maintained break and quit being able to be used, because some variable or another got changed. It's a very bad situation for backwards-compatibility.

[imbaczek]

The config file instead of Registry entries is not too big of a deal, I guess. I'm really questioning why following Microsoft's standards is such a big deal, though, when it means multiple engine installs could possibly cause serious conflicts between different versions of the engine... because one supports config variable A, and the other one supports ABC... or in one A can be a float, in another only a boolean or integer... this seems fairly dangerous, in terms of true portability.

this is a problem that we are aware of, and it is easy but tedious to fix. we lack man- and willpower for such jobs, very unfortunately imho. basically, we should provide a config migration tool for each engine upgrade, but there's nobody who could take care of it ATM.

That... and how can any application claim to be "portable" when you cannot run it from a thumbdrive? That's where I'd set the target, imo.

the next version will finally properly support --config command line option. with proper lobby/launcher support, this becomes a non-issue. (springlobby has support for this coded AFAIK.)

different people's requirements are not compatible in this regard, so we go with the recommended way (notice most, if not all, new games do that, too.)

[AF]

Actually the reasoning behind it by microsoft was quite clear and if anything 'linux inspired'

According to microsoft:

• Dont use the registry because its a mess we wish we could get rid of
• Don't store stuff in program files thats meant to be writtable, that folders read only to help prevent malware modifying your programs

Linux users have a similar predicament.

I would ask that we allow spring to look for an options file in the current working directory however aswell, as a means of making support on thumbdrives easier

[Auswaschbar]

I would ask that we allow spring to look for an options file in the current working directory however aswell, as a means of making support on thumbdrives easier

Not much of an issue, since you can tell spring where to look for the config file, as others already stated. Additionally, I am planning to release a fully portable version of spring + springlobby for 0.79.

In the long run, ti would be neat to have better config support in general, which includes, but is not limmited to:

• unified config handlers (allow to set the same variables on commandline, in the config file, in the script.txt, ingame ...)
• support for multiple config files
• support for optional per-mod configurations

[lurker]

Argh, before you rant, please explain where such a shared text file would go. Install directory isn't writable; this would be a gaping security flaw to have the trusted-to-be-installed binaries changeable by anyone. Next.

I still think that its the responsibility of game developers in this community to package their own content into their own installers.

This. zwzsg gets it, Argh gets it, S44 team gets it, only *A people need some... attitude adjustment

CA will go looking for new people to install when CA pleases.
BA clearly doesn't need to have an installer or do anything to get players.

And if installers are mandatory, would you really run one for each of KDR's games, each *A variant, etc.?

[Pxtl]

That's a good point. I don't think Spring players would really want the KP-branded Spring installer or the PURE-branded Spring installer, more like they'd simply want "Spring installer bundled with game X and mod X's single-player launcher", but without feeling like they don't have a "vanilla" install of Spring.

[imbaczek]

i'm not saying we should stop providing engine installers. the game/mod installers should simply provide everything what's needed to actually _play_, (ie. the mod and some maps) so new players don't install the game, go into #newbies and are be asked to download 200MB of additional content. that's what i mean by getting things right - you want to introduce a player to the game, you point him at something that actually works right after installation.

this doesn't affect current player base in any way btw, it's not for them.

[zwzsg]

1. Spring and associated programs need to quit using the Registry at all. Use text files in the root install directory. Keep it all portable, and don't screw up multiple installations of the engine.

won't happen, it's against MS software guidelines. configuration is stored in a text file in Local Settings/App Data, every user has his own.

Then at least make it so the config written by one Spring doesn't make another Spring crash! (Like current Spring and next Spring due to some font setting).

[lurker]

i'm not saying we should stop providing engine installers. the game/mod installers should simply provide everything what's needed to actually _play_, (ie. the mod and some maps) so new players don't install the game, go into #newbies and are be asked to download 200MB of additional content. that's what i mean by getting things right - you want to introduce a player to the game, you point him at something that actually works right after installation.

this doesn't affect current player base in any way btw, it's not for them.

How is this not the way it works right now, except that there are no *A versions?

[zwzsg]

I don't think Spring players would really want the KP-branded Spring installer or the PURE-branded Spring installer, more like they'd simply want "Spring installer bundled with game X and mod X's single-player launcher", but without feeling like they don't have a "vanilla" install of Spring.

I agree, in that I don't feel that having one Spring install for every mod is really that desirable. But then I also understand that finding out a new Spring release went out and breaks your mod and you have to fix in a hurry is also highly annoying. In an ideal world new Spring release would add new features, not break old ones, but sometimes I get the impression the concept of retro compatibility has been lost when #sy got replaced by new devs (but I also understand how it can be tricky to keep total retro-compatibility on such a large and complex project with mod makers too stupid to do things cleany on the first place and expecting hacks to remain).

[BrainDamage]

sometimes I get the impression the concept of retro compatibility has been lost when #sy got replaced by new devs (but I also understand how it can be tricky to keep total retro-compatibility on such a large and complex project with mod makers too stupid to do things cleany on the first place and expecting hacks to remain).

defective by design cannot be fixed while maintaining retro compatibility

[Neddie]

sometimes I get the impression the concept of retro compatibility has been lost when #sy got replaced by new devs (but I also understand how it can be tricky to keep total retro-compatibility on such a large and complex project with mod makers too stupid to do things cleany on the first place and expecting hacks to remain).

defective by design cannot be fixed while maintaining retro compatibility

Exactly.

[imbaczek]

lurker: it's exactly like that except *A is mainly what people come here for and they are the ones who have the most trouble getting into the game.