Installer

[Tobi]

Recently I've noticed several people have the intention to make content packages including Spring, or automated update programs, so I'm wondering what the point for me is to spent time updating our "official" installer with better content.

I see basically two ways to continue from here, which are:

1) I rip all content out of the 'official' installer, and let you, the community, build huge installers with everything in it based on the small bare bones installer we'd release.

Pros are I don't have to care about it; someone else gets to distribute the OTA content.

Cons are a possible wildgrow of installers; possibly lower quality on some packages; packages being made once and then forgotten, never being updated.

2) Someone volunteers to maintain, update (e.g. rerelease if new versions of mods are out) the official installer. You would then of course get full responsibility for it and commit access and be part of the Spring team.

Pros are less confusion for nubs about which installer to download; because there's only one installer all community effort can be directed at improving that one, hopefully resulting in a higher overall quality.

Cons are possibly still OTA content being distributed (though this would be up to the person doing the installer); buildbot spending more resources on installer (building) cause the package would (probably) be bigger.

So, what are other (content) developers' opinions about this, did I forget options or pros/cons, or is there someone who likes to volunteer as installer maintainer right now? (that would be nice )

[LordMatt]

What would the duties be of the installer maintainer? Just deciding what maps and mods to include in the official installer? What level of skills would be required to maintain the installer, just moving files into the SVN or something more complex? I might be interested if I were sure my lack of coding skill wouldn't be a burden on the devs.

[Tobi]

Not just deciding, but deciding and modifying the installer.

Which usually comes down to adding some File "path/to/bla" directive to the install part of the installer and a Delete "$INSTDIR/bla" directive to the uninstall part of the installer, and putting the file on buildbot.

Modifying the sections/sectiongroups at times may be useful too. For most useful cases however example code is already there, because we already got some sections and one sectiongroup.

IOW, a little NSIS skills doesn't hurt, just take a look at the .nsh/.nsi files in trunk/installer and trunk/installer/sections and see if you understand the basic structure.

Of course you can always try to delegate the more complex stuff to other people again

[KDR_11k]

Would also be nice if it didn't overwrite files like uikeys if they exist already.

[AF]

I think we should move out all the mod and map related stuff into external script files. We already have maps.nsh, and there'd need to be a file containing the specific data such as replacing strings such as 'spring' with 'spring + modname' etc

[LordMatt]

Would also be nice if it didn't overwrite files like uikeys if they exist already.

According the the code it isn't supposed to:

Code: Select all

!ifndef SP_UPDATE
  File "..\game\settings.exe"
  File "..\game\selectkeys.txt"
  File "..\game\uikeys.txt"
  File "..\game\cmdcolors.txt"
  File "..\game\ctrlpanel.txt"

Which I take to mean if it is not an update install add these files.

I think we should move out all the mod and map related stuff into external script files. We already have maps.nsh, and there'd need to be a file containing the specific data such as replacing strings such as 'spring' with 'spring + modname' etc

I'm not sure I understand what you are suggesting. I will take mods out of main.nsh and make their own file mods.nsh (or I could even make specific *.nsh for specific mods).

[AF]

The point is then you have a bare bones installer, and all the customized stuff is in header files on their own. That way for the new guy wanting to make an installer all they have to do is edit mods.nsh and maps.nsh accordingly, and there's no need to bother figuring out the structure of the entire installer script.

[LordMatt]

Well you would still have to reference those headers in the main installer script (if you wanted to do something beyond mods and maps). I think the only customized stuff that is still in the main installer script is XTAPE.

[HeavyLancer]

I will volunteer to maintain the installer, as I am working currently on a content package in a similar vein. I have a few NSIS skills I learned whilst making my last installer, and maintaining a package shouldn't be too hard. Plus, I currently have a lot of spare time until the beginning of February.

[LordMatt]

Nice! So tobi and I have worked out a few details so far:

OTA Content and Mods will be downloadable through the installer, rather than being directly included (thus eliminating the problem of including OTA content in the installer). We will have to decide on a list of mods which are reasonably stable, as the installer will have to be rebuilt when a mod's file name changes (i.e. when a new version is released). A work around tobi suggested was to store the names of the of the mod files in a text file on the server that the installer downloads and inspects, that way only the text file would have to be changed in between spring releases to ensure that the latest version of the mods were downloaded. This work around would require more skill with NSIS than I have (I understand the basics and can edit the stuff that's already there, but this is probably beyond me at this time, or time than tobi has). Another small project is making downloading and installing the OTA Content required for downloading and installing any of the Total Annihilation based mods. There is a function that does something similar for the shortcut for the lobby, but I was planning to try to understand that function last, after making the simpler changes.

Maps: Because we can have content downloadable through the installer, we could probably make several map packs that are referenced by it, e.g. 1v1 map pack, teamplay map pack. For large map packs maps in particular, however, we will have to ask Cup's permission to use direct downloads from UF. I will discuss this with him next time he's on.

[smoth]

Lordmatt the map idea is good but with uf in shambles I would hate to ask anything from cuppy other than he repair the site.

[LordMatt]

Well please tell cup what is in shambles about UF he's under the impression that it is mostly working. Also all I need to ask is permission, I can take care of the rest.

[smoth]

oh my god, how can he say that....

admin is broken, the pictures are all gone, the old file links are all broken... soo many problems.

[LordMatt]

admin is broken

Well the part that he has finished works fine for me. The rest will come.

the pictures are all gone

Nothing he can do about this, they were wiped from the server and there was no backup.

the old file links are all broken

Are you referring to the links inside of the lobbies? These will be fixed with the next release.

[smoth]

http://spring.unknown-files.net/file/2898/Gundam_1.11_/
links are broked

Image thumbnails in the latest files section are gone.

I am/was an admin, I cannot update files any more. Bad enough that I spent days straight updating pics for the maps. Now I cannot even start that over again because I cannot modify file details.

so all the pictures are gone? That really sucks it took a looong time to do those pictures. Oh well as soon as admin is fixt I can start anew.

Also when you click on an image thumb that java window thing runs slow as hell. It make browsing image a pain, I miss the old method.

[ZellSF]

Well please tell cup what is in shambles about UF he's under the impression that it is mostly working. Also all I need to ask is permission, I can take care of the rest.

Well, the shitty javascript detection script needs to either be fixed or removed. I've ended up on non-exisiting pages because of it multiple times.

[FLOZi]

Well please tell cup what is in shambles about UF he's under the impression that it is mostly working. Also all I need to ask is permission, I can take care of the rest.

Well, the shitty javascript detection script needs to either be fixed or removed. I've ended up on non-exisiting pages because of it multiple times.

A huge +1

[KDR_11k]

I think the only mods that are stable enough to update less often than the installer are AA (until Caydr becomes active again), WD, Gundam and XTA and even then we'll have the NTAI issue that if the mod releases a new version most people will still have the outdated one. So the only real way would be to do dynamic downloading.

Smoth, you can't go to the admin panel but you don't need it anymore either, now you can just go to the file you want to edit and all the options are there.

[Tobi]

As said, LordMatt and I already discussed it, and we consider it possible to rebuild the installer with everything the same except a newer version of some mod, in between Spring releases.

[YokoZar]

Regarding Ubuntu packages:

APT allows us to do everything you're trying to do with the Windows installer simply and easily. Once I make a spring-mods-balancedannihilation package, all I need to do is update it and push it to the apt server to keep everyone up to date with the latest balanced annihilation. The same thing goes for lobby clients, the game engine, and even the maps installed by default.


A more interesting question, of course, is what should the default packages included be when a user follows the bare wiki instructions. I'm tempted to just include everything as a dependency of some wrapper package, so when you apt-get install spring it also installs all mods and maps currently packaged.