Task: Map/mod install tool

Tobi · Post by **Tobi** » 09 May 2007, 10:49

Before 0.75, we still need this.

This would be a small program in the Spring installation which would be associated with the .sdz and .sd7 file types. If it was launched on such a file (open instead of save as in browser, double click on it on desktop, etc.), it'd install it to the right subfolder of the Spring install folder.

It should be really minimalistic IMHO:

Written in C/C++, to not introduce enduser dependencies on other runtimes for a small tool like this.
Preferably it should be possible to compile it with MinGW (but of course MSVC++ (Express Edition) can be used to make it).
It is started with one argument, the full path to a .sdz or .sd7 file.
It should examine the file.
If it is a map, it should put it in the Spring's maps folder. It can find this folder because it is stored in Spring's folder itself, so it can extract the path from the commandline it was invoked with (the 0th argument).
If it is a mod, it should put it in the Spring's mods folder.
It should then give a message box "The mod/map blabla has been saved succesfully to <path>, use the reload mods/maps button in the lobby to make Spring find it."

Regarding implementation, I think it is easiest done by just using unitsync. The VFS in unitsync uses the current directory as data directory so the tool can just chdir to the directory of the file and examine it. It may need some modifications to unitsync so it doesn't write e.g. ArchiveCacheV4.txt...

Then it may be possible to just use the unitsync functions for retrieving maps and mods, or otherwise coding up something using the VFS functions in there, mimicking the code to determine whether something is a map/mod in ArchiveScanner.cpp (probably the tool should do nothing if a file is both map AND mod).

When the tool is finished one needs to figure out how to put the right registry key creation code in the installer to associate this tool with .sdz and .sd7 if they aren't associated with another program yet.

Bonus points if it works in Linux too, including the necessary .desktop files for file associations in Gnome/KDE. This would require some trickery with the multiple data directory code however.

I post this here knowing someone can pick it up more easily if it's clearer what is wanted and how it may be implemented

Maelstrom · Post by **Maelstrom** » 09 May 2007, 12:54

Ive got a half completed one using Visual Basic and the stand alone 7-Zip program. I can finish it for you if your interested.

Tobi · Post by **Tobi** » 09 May 2007, 14:17

Hmm, so it depends on an existing installation of 7 zip? And can the express edition of VS compile standalone exes of Visual Basic?

I'd rather see something without external dependencies besides those already introduced by Spring though. Also we have like 10 languages in use already, which is kinda enough IMHO, especially when we're talking about apps this small.

Maelstrom · Post by **Maelstrom** » 09 May 2007, 15:11

There is a stand alone .exe that comes with 7z. I was just planning to use that, then 7z doesnt need to be installed.

Visual Basic can usually make stand alone programs, its only when you start using really specialised controls and stuff that you need dependancies. Im pretty sure that what Im making would run straight out of the box, but it would not be linux compatible at all.

Post by **trepan** » 09 May 2007, 16:34

Here's some C++ code I started a while ago to do this task,
and then left it hanging (I don't find it all that useful for myself,
so my interest is very low). The file type detection part is done
using the same compression libraries as Spring. Moving the
file is the part that needs to be finished, iirc.

http://trepan.homelinux.net/spring/ArchiveMover/
http://trepan.homelinux.net/spring/ArchiveMover.zip

P.S. The source should go in the tools/ directory.

Tobi · Post by **Tobi** » 09 May 2007, 19:20

Ah that seems like a nice setup already, even though slightly different from my original idea to use unitsync.

zwzsg · Post by **zwzsg** » 11 May 2007, 08:33

I wish it also installed AI, because:
- the AI folder trees is more confusing than /maps/ and /mods/
- AI are meant to used to people who won't join the chat and be explained what to do.

If it also installed AI profiles & configs, that'd be super-nice, but maybe AI profiles & configs are too specific to each AI to be known by a general install tool.

And there's also the problem that the install tool can't claim .dll for itself.

Neddie · Post by **Neddie** » 11 May 2007, 08:34

Yes. Win! Epic, this helps me out to a great extent.

Comp1337 · Post by **Comp1337** » 11 May 2007, 08:45

Ive another solution that i use personally. Add 'mods' and 'maps' to SendTo, then you can just rightclick and whammo.

Ofc, only windows afaik.

AF · Post by AF » 11 May 2007, 11:02

AIs are indeed to specific but I should have a solution to that predicament in time.

chlue · Post by **chlue** » 11 May 2007, 13:24

If it also installed AI profiles & configs, that'd be super-nice, but maybe AI profiles & configs are too specific to each AI to be known by a general install tool.

I don't think AI's are to specific. Maybee I miss something, but afaik all AI's are installed by placing the dll in the directory \AI\Bot-libs\AIName.dll
and any helperfiles in \AI\AIName (talking only about windows)

So if all AI's are packed in something like this:

Code: Select all

\AI\Bot-libs\AIName.dll
\AI\Bot-libs\AIName.so <-- for Linux?
\AI\AIName\...
          \...

and this archive gets an unique extension, for example aiz and ai7 for zip/7z archives, than an installer should have no trouble to decompress any AI.

A step further would be a short xml-file with describes where to place the files. (Or just the rule to always include all necessary directorys, so simply decompressing in the spring directory would be sufficient) Then we could use one extension and install Bot-libs, Helper-libs and LUAWidgets with it. Experienced users could still simply decompress the archieve to look inside.
I primary see two problems with that:
1. What should the installer do if the file allready exist (overwrite - ever/never/userdefined/provided with the file).
2. We need to make sure, that only some specific directory have write permissions

Maybee its only so easy for Windows, but there is probably the main playerbase that have trouble installing this stuff by hand.

AF · Post by AF » 11 May 2007, 13:35

You have configs too.

For NTai configs I assume its going to be extracted into the main spring folder so I put the necessary folder structure inside the archive.

So there's /config.zip/AI/NTai/

However I agree a system such as xml configs should be used but there's already one in place, modinfo.tdf.

Maelstrom · Post by **Maelstrom** » 11 May 2007, 15:04

Well for whoever makes this, this is what I was planning for my Auto Install. There seems to be much better options avaliable than my VB program, but the idea could be implemented anywhere.

Basically, every Spring map/mod/AI/LUA/etc would be put in a .sdz/7, with a file called 'auto.tdf' in its base directory. 'auto.tdf' would be structured like so:

Code: Select all

[AUTO]
	{
	name=Testing;
	author=Maelstrom;
	description=A Test archive for auto installing;
	folder=test/test/;
	extract=1;
	}

The tags mean:

Name: The name of the map/mod/etc.
Author: Who made the file.
Description: What the file is.
Folder: Where to install the file.
Extract: If set to 0, just copies the .sdz/7 to the specified install path, if set to 1 extracts the contents of said file to the install folder. Non-extracting would be used for maps/mods, while extracting could be used for installing AIs/LUA.

chlue · Post by **chlue** » 11 May 2007, 15:49

I spend some more thoughts in it and I fear it is a bit more complicated.
It should be quiet easy to scan a single sdz or sd7 file and decide if it is a map or a mod and copy/move the file to the right spring directory, but for the rest we would need something more complex.

For example:
- Gundam comes in a zipfile that contains three sdz files.
- most mods in a zipfile have a readme attached
- if you update AAI you should delete the old learning files

There is probably a lot more. So I think to handle this, we need to define something like a 'spring content package'-fileformat. This scp-files would be simply renamed zip/7z files. The fileextension can be linked to an installer who should at least allow the following:
- extract files to the defined directory (could be done by simply adding the necessary paths to all files in the archive)
- protect certain folders/files
- show a short description
- provide a way to show the readme (if provided)
- provide a way to open the homepage (if provided)
- display a warning for content who is possible dangerous to the system (third party AI's)
- maintain a list of current installed 'addons'
- delete old/unwanted addons and the stuff they created
- display a warning if there is a obvious confict

A good example is the Mod-Manager for the game Freelancer

smoth · Post by **smoth** » 11 May 2007, 16:27

in the case of spring though, we do not have to remove a package in order to play another one

Erom · Post by **Erom** » 11 May 2007, 18:09

The FMM was pure win, I'd love to see it implemented like that (with, obviously, Smoth's addendum)

Would it not also be nice (for a later version, probably) if the .scp file could specify a URL to check against for a new version of the file? Would make updating something pretty damn easy.

AF · Post by AF » 11 May 2007, 22:55

overkill overkill overkill

Your all discussing a problem that has already been solved by 3 people me, jelmer and fnordia.

Fnordia created the mod system we use today. modinfo.tdf contains 99% of all you discussed, it even goes on to mention dependencies, the only thing it lacks is a path to where the archive should be.

Ontop of that, jelmer has a package management system and I have a package management system and they're 99% complete, and we're both waiting for iamacup to give us the backends to Unknown files we need.

As far as I'm concerned everythings sorted, and the only thing that merits discussion in this issue is trepans tool and its completion.

To this end, add installpath=; tag to the modinfo.tdf file and your done.

e.g.

Code: Select all

[MOD]
{
	Name=SimBase a24;
	Description=PorkSpaemPorkSpaem;
	URL=http://taspring.clan-sy.com/;
	ModType=1;
	NumDependencies=2;
	Depend0=bitmaps.sdz;
	Depend1=springcontent.sdz;

	InstallPath=mods;
}

You're all trying to re-invent a system already in place.

Tobi · Post by **Tobi** » 12 May 2007, 12:27

+1

It's unrealistic that 8G of mods and maps is rereleased just to include a new textfile.

The only thing that we want, is a tool which determines whether a .sdz or .sd7 file is a map or a mod, and which puts it in the maps or the mods folder of the Spring install.

If a mod is released as .zip, then it's the modders problem, it's not the goal of this thing to be a general purpose archive extraction tool that also knows where to put the contents. The modder could also have packed it in a installer in that case or a self extracting zip or whatever. And in the end a user can just extract the zip and run the tool on all the .sdz and .sd7 files in it (as in, select them all -> open).

We also don't need an installpath variable in modinfo.tdf for the first version and there is no need at all for AI support (well, there is need, but it's too complex).

If someone finishes trepan's code to actually compute the Spring directory, move the files there and show a MessageBox then I'm happy.

KDR_11k · Post by **KDR_11k** » 12 May 2007, 12:41

Doesn't mean we can't say future files should add that tag for easier categorizing.

Tobi · Post by **Tobi** » 12 May 2007, 12:44

It should be recommended for files for which the categorization may be ambiguous, yes. (think of shared content packages that should go in "base")

EDIT: the tool should also refuse to move files already in the Spring install, otherwise it's too easy to mess up stuff.

Spring RTS Engine

Task: Map/mod install tool

Task: Map/mod install tool