Spring RTS Engine

The problem I see is: how to manage multiple game installs?

E.g. if each game has its own installer what should happen if you install multiple of those? It doesn't make sense to install lobbies twice and use them to connect to the same server ...
Shouldn't there be a default installer framework that merge those installs into one?

I think we need a package management system.

Games should install with their respective copy of spring and their game content, into program files, and then use the shared spring folders for maps etc, to prevent duplication.

I expect additional options such as installing into a combined install to be made available, but there is the issue of games choosing to support a specific version of spring, and wanting to update themselves rather than chasing the current spring latest all the time.

For example, my fictional game, AquamanRTS, is about to be mothballed while I go on a 5 year vacation to Tibet to meditate away from technology. I would like my installer to make sure my game uses the current working version, and that when my game breaks in the next version, it continues to work using the engine version I selected.

^^ This ^^

No one in their right mind is going to migrate away from the shared spring stuff, so your concern is pretty much a non-issue.

Installers that have been pushed out already are always accompanied by one of the following:

• Standalone archives for the shared installs
• Forum members demanding standalone archives for shared installs, followed by their release shortly afterwards

jK wrote:The problem I see is: how to manage multiple game installs?

E.g. if each game has its own installer what should happen if you install multiple of those? It doesn't make sense to install lobbies twice and use them to connect to the same server ...
Shouldn't there be a default installer framework that merge those installs into one?

My installer detect the windows install entries of a previous Spring install, and use it for the default install folder than the intaller propose. Then, it compare the filesize of spring.exe with a list of known size to know if it's an old Spring install, or a newer Spring install. If newer, then it unticks the installing of the "spring engine" part.

So the default value provided by my installer ensure it reuse any existing Spring install, and to update only if necessary. But user still has the liberty to change install folder, to untick or retick the spring engine part.

how about to check the version string if this works in windows, too D:
if you are using nsis, it should be possible via

Don't all mods with installers also come in a non-installer version? I just use the KP installer to get Spring and then plug other stuff in with versions that don't include Spring.

t0rb3n: Would not work retroactively, so I'd still need another method for all the old versions. Also, the format of Spring version string keeps changing. Lastly, Spring version string aren't a simple single number so are hard to interpret.

KDR_11k wrote:I'd suggest Spring Platform since it's not just an engine, it also comes with a lobby and master server.

I still want the RTS word in. Spring RTS System, Spring RTS Platform.

Anything except Engine, which magically makes me think of trains.

Please make more name suggestions and then it is poll time.

We have enough muddles over wether we're in spring with our daffodils, or in a spring thats about to snap into the air, or if we're springing forwards to a bright new future.

Vi sitter här i venten och spelar lite DotA
å springer runt å creepar, och motståndet vi sleepar.

zerver wrote:Anything except Engine, which magically makes me think of trains.

Oh, right, Spring doesn't have a train simulator mod yet...

KDR_11k wrote:

zerver wrote:Anything except Engine, which magically makes me think of trains.

Oh, right, Spring doesn't have a train simulator mod yet...

not yet is not nyet, am i right?
http://img695.imageshack.us/i/centailcontrain.jpg/

Slightly related: We in agreement now that things such as Kernel Panic and Complete Annihilation are referred to as games. Mods or modifications apply to things like BA which are modifications of OTA? Where do we stand on that?

Regardless, the mod folder in the Spring directory should be renamed to games and every other reference should change from mods to games. Mods implies that they're all modifications of a default Spring game which does not exist.

Installing to the games folder by default and keeping the mods folder would make more sense as those with an existing mod folder, and pedantic new players would be displeased by the change

this will not happen. it is too much work for no practical gain. it's not like we had too much dev time, you know.

hoijui wrote:this will not happen. it is too much work for no practical gain. it's not like we had too much dev time, you know.

Could you be more specific as to what will not happen?

Jazcash wrote:Regardless, the mod folder in the Spring directory should be renamed to games and every other reference should change from mods to games. Mods implies that they're all modifications of a default Spring game which does not exist.

This is what he's almost certainly referring to - I'd think AF's suggestion (while non breaking), likely folds in with it as well, cause it still requires renaming references, etc, for what is basiclly a cosmetic change --> zero ingame benefit (though I too can see the reasoning behind it).

My change rewires that only the installer and archive mover be changed, for archive mover it's an absurdly simple search and replace, and for the installer it's as simple as merely creating a games folder, something we already do for the others so it's actually a copy paste

As for the engine itself, we already have tags differentiating names and games, and iirc we already have archiveinfo.lua or something similar as an alternative to modinfo.tdf, and we already have a full complement of tags for both mod AND game names, which were added almost a year ago.