engine installer should block installing over old install

[PepeAmpere]

Propoganda? I didn't mention or have any particular lobby in mind. Maybe some can but most can't; the ones I would need to certainly can't. In any case, this discussion is about the engine installer and really only relates to SpringLobby.

Other options are portable packs or lobby-driven installers which does not need Springlobby and their existence is prove that any engine installer is not needed. So, it relates a lot, thats what we are talking about.

[Silentwings]

No, this topic is about if the engine installer (see front page of website) should allow overwriting or not. You might be talking about other things, I was not!

[smoth]

Other options are portable packs or lobby-driven installers which does not need Springlobby and their existence is prove that any engine installer is not needed. So, it relates a lot, thats what we are talking about.

If people don't have access to engine installs HERE where will we get the latest engine files? INBEFORECOMPILEYOUROWN.

One of the biggest problems with spring is people seem to believe it is the engine's responsibility to update the player. generally because that is how it worked for *a for years. Even gundam(with the help of zwzsg) had an installer. If we want to talk about spring installs, we could always have users installing say /games/zero-k, games/BAR, games/evo.... you know like they do for "real games"

Or we could be smarter and more forward looking. Using the lobbies as some sort of steam like hub for any project done on this or future versions of the engine. Which is why I want the engine version in a sub dir and the mod to at least contain some kind of OPTIONAL tag which would state minimum version of the engine.

updating that part of the modinfo is the module devs responsibility imo. Add more robust support could happen in the future but for now these are my thoughts on the matter.

[gajop]

Or we could be smarter and more forward looking. Using the lobbies as some sort of steam like hub for any project done on this or future versions of the engine. Which is why I want the engine version in a sub dir and the mod to at least contain some kind of OPTIONAL tag which would state minimum version of the engine.

This imo.
Although I think custom installers are bad. Rather have lobbies that open some really simple .spring files (e.g. pr-downloader install calls) after the installation.

[smoth]

well single installers is how we are doing things now. if the lobbies moved towards a more hub based approach it would be more efficient imo... so yeah definitely not a fan of all the individual installers.

[FLOZi]

OMG finally a stance on installers I can get on board with. I've never really found the 'each game has it's own installer' paradigm to be a sensible course; surely Spring's USP is that it is many games on one platform?

The situation is partly complicated by the fact that base-content can change with engine version too, particularly as the lua api shifts - so base content might start using a new function that wasn't available before or params have changed, so we can't always use the latest base content with older engines.

I would rather (and have done something like - Getting SL to play ball wasn't easy, WebLobby does something similar to this);

%SPRING%
%SPRING%/Engine/<basically each version using current min-portable builds>
%SPRING%/Games/<sdz and sd7 here>
%SPRING%/Maps/<sdz and sd7 here>

Then follows problems about how to control engine settings and luaui settings etc etc etc (userland luaui is the devils work)

IMO there should also be a separate engine-only installer with e.g. mapconv, ToolBox, ScenEd, Upspring (yes, yes I know) etc. for potential engine end users [as opposed to players].

[smoth]

OMG finally a stance on installers I can get on board with.

it is amazing how people who have spent this much time doing what we do here converge isn't it?

[Silentwings]

OMG finally a stance on installers I can get on board with. I've never really found the 'each game has it's own installer' paradigm to be a sensible course

I also agree but am not sufficiently aged as to share in your pathos...

[PepeAmpere]

%SPRING%
%SPRING%/Engine/<basically current min-portable>
%SPRING%/Games/<sdz and sd7 here>
%SPRING%/Maps/<sdz and sd7 here>

Thats what we are talking about for almost one year (me, danil and some others). If you make engine fit this, we save player a lot of issues with updates, devs testing/updating the games for upcomming versions, etc.

So i suggest:,

• portable fit this perfect => use portable Spring,
• make this folder structure and have some lobby which understand such structure (ZKL, NL, WL)
• influence engine devs to dont change folder structure in new releases much and support them if they prefere portable solutions

No, this topic is about if the engine installer (see front page of website) should allow overwriting or not. You might be talking about other things, I was not!

MY STATEMENT: This topic suggest something, what we dont need :) I think thats proper reaction in some topic to say its bad topic, isnt it?

[smoth]

%SPRING%
%SPRING%/Engine/<basically current min-portable>
%SPRING%/Games/<sdz and sd7 here>
%SPRING%/Maps/<sdz and sd7 here>

Thats what we are talking about for almost one year (me, danil and some others). If you make engine fit this, we save player a lot of issues with updates, devs testing/updating the games for upcomming versions, etc.

So i suggest:,

• portable fit this perfect => use portable Spring,
• make this folder structure and have some lobby which understand such structure (ZKL, NL, WL)
• influence engine devs to dont change folder structure in new releases much and support them if they prefere portable solutions

so knorke, flozi and I all agree... does that NOT show enough support for a request?

[gajop]

%SPRING%
%SPRING%/engines/<with each engine having its folder like with ZKL>
%SPRING%/games/<sdz and sd7 here>
%SPRING%/maps/<sdz and sd7 here>

Mostly agree, but I think we should have multiple engines in that folder, not just one. Also folder names should be in all lowercase due to legacy reasons.

IMO there should also be a separate engine-only installer with e.g. mapconv, ToolBox, ScenEd, Upspring (yes, yes I know) etc. for potential engine end users [as opposed to players].

What do you mean by a 'separate installer'? Anything involving separate installation methods (e.g. new wizards & stuff) is wrong.

In fact it makes sense to bundle things (by including the proper rapid tags) in the game as per game devs wishes. This is what pretty much every single game out there does it, and it makes sense. People using these tools (mostly just GUI stuff with no code) aren't even what you normally consider devs, they are not experienced.

[FLOZi]

%SPRING%
%SPRING%/engines/<with each engine having its folder like with ZKL>
%SPRING%/games/<sdz and sd7 here>
%SPRING%/maps/<sdz and sd7 here>

Mostly agree, but I think we should have multiple engines in that folder, not just one. Also folder names should be in all lowercase due to legacy reasons.

Sorry - that is what I meant, edited the above for some clarity.

IMO there should also be a separate engine-only installer with e.g. mapconv, ToolBox, ScenEd, Upspring (yes, yes I know) etc. for potential engine end users [as opposed to players].

What do you mean by a 'separate installer'? Anything involving separate installation methods (e.g. new wizards & stuff) is wrong.

In fact it makes sense to bundle things (by including the proper rapid tags) in the game as per game devs wishes. This is what pretty much every single game out there does it, and it makes sense. People using these tools (mostly just GUI stuff with no code) aren't even what you normally consider devs, they are not experienced.

As in 'If you want to play games with Spring, grab this [lobby], if you want to make games with Spring, grab this [package of stuffs which optionally downloads latest engine version too]'

[PepeAmpere]

was confused too, of course im for "engines" folder, not "engine" folder :)

[Forboding Angel]

It should be done the way that weblobby does multi engine. Weblobby does it in a very clean fashion (IE downloads minimal portable and unzips it in a folder name that is the engine version and that is that. From what I can tell, zkl does some weird ass mangling of the engine files after it unzips them.

[Google_Frog]

It should be done the way that weblobby does multi engine. Weblobby does it in a very clean fashion (IE downloads minimal portable and unzips it in a folder name that is the engine version and that is that. From what I can tell, zkl does some weird ass mangling of the engine files after it unzips them.

As far as I can tell ZKL and weblobby have the same engine installer system.

[scifi]

Or we could be smarter and more forward looking. Using the lobbies as some sort of steam like hub for any project done on this or future versions of the engine. Which is why I want the engine version in a sub dir and the mod to at least contain some kind of OPTIONAL tag which would state minimum version of the engine.

Arent they already like that? (but less neutral than steam), the only thing your adding is multi engine support, witch they already sort of support, but with a different file structure.

Talking about the topic at end, blocking installing over old instalation seams a more lobby based functionality than anything else, unless spring installer would warn you if you were installing under a folder with "spring.exe on it".

A steam hub is sort of a Single lobby system, that has its own file structure with games etc..

However spring lobbys are all about what people are playing at the moment and not what games spring supports.

[PepeAmpere]

It should be done the way that weblobby does multi engine. Weblobby does it in a very clean fashion (IE downloads minimal portable and unzips it in a folder name that is the engine version and that is that. From what I can tell, zkl does some weird ass mangling of the engine files after it unzips them.

As far as I can tell ZKL and weblobby have the same engine installer system.

Similar to Notalobby

[abma]

fyi: https://github.com/spring/spring/commit ... 9dcc79fe54 makes the spring installer asking for uninstall when it detects an already existing installation in the destination dir.

not sure if with spring 97.0 lobbies can be already removed from spring installer.

[smoth]

Does that remove config files also?

[abma]

no, thats not possible as the installer is run as different user (admin) and its difficult to touch user files. it would have to delete all config files from all users on the system. lobbie(s) have to do so or spring itself.