Page 1 of 3
Spring SDZ Mod/Map Installer
Posted: 07 Apr 2007, 23:32
by AF
Spring SDZ Mod/Map Installer
A java program that autoinstalls maps and mods using the sdz extension to your spring folder by double clicking on them.
Extract these files into your spring folder, then associate the .sdz file extension with the spring_archive_installer.bat file. Then double click on a mod or map with an sdz extensionf ro ti to eb automagically installed.
Posted: 08 Apr 2007, 01:12
by pintle
surely you should be giving yourself cookies for this?
Posted: 08 Apr 2007, 01:43
by gamer17
lol
Posted: 08 Apr 2007, 03:02
by rattle
Uh... I think I'm faster with moving maps/mods with a single keystroke.
Posted: 08 Apr 2007, 03:39
by zwzsg
Does it unzip mods/maps that are zipped?
Does it install AI? Even those that go into /AI/Bot-libs/ instead of /AI/ ?
Do you know that most maps/mods use sd7 and not sdz?
Posted: 08 Apr 2007, 03:41
by iamacup
does this work on metadata? or just filetype
Posted: 08 Apr 2007, 04:26
by AF
most mdos would use sdz because its faster.
And it looks inside the archive and tells if its a map r a mod. If its soemthign else it ignroes it atm.
and it doesnt install AIs atm.
And no it doesnt handle .zips containing mod archives, just .sdz files.
Here is the source code:
Code: Select all
/*
* Main.java
*
* Created on 07 April 2007, 21:32
*/
package springarchiveinstaller;
import java.io.*;
import java.nio.channels.FileChannel;
import java.util.Enumeration;
import java.util.zip.*;
/**
*
* @author Tom
*/
public class Main {
/** Creates a new instance of Main */
public Main () {
}
/**
* @param args the command line arguments
*/
public static void main (String[] args) {
// TODO code application logic here
try {
// Open the ZIP file
ZipFile zf = new ZipFile (args[0]);
// Enumerate each entry
for (Enumeration entries = zf.entries (); entries.hasMoreElements ();) {
// Get the entry name
String zipEntryName = ((ZipEntry)entries.nextElement ()).getName ();
String z = zipEntryName.toLowerCase ();
if(z.contains (".sm3")||z.contains (".smf")||z.contains (".smt")||z.contains (".smd")){
// copy the file over to c:/program files/spring/maps/
File f = new File (args[0]);
// Create channel on the source
FileChannel srcChannel = new FileInputStream (args[0]).getChannel ();
// Create channel on the destination
FileChannel dstChannel = new FileOutputStream ("maps/"+f.getName ()).getChannel ();
// Copy file contents from source to destination
dstChannel.transferFrom (srcChannel, 0, srcChannel.size ());
// Close the channels
srcChannel.close ();
dstChannel.close ();
f.delete ();
return;
}else if (z.contains ("modinfo.tdf")){
//
File f = new File (args[0]);
// Create channel on the source
FileChannel srcChannel = new FileInputStream (args[0]).getChannel ();
// Create channel on the destination
FileChannel dstChannel = new FileOutputStream ("mods/"+f.getName ()).getChannel ();
// Copy file contents from source to destination
dstChannel.transferFrom (srcChannel, 0, srcChannel.size ());
// Close the channels
srcChannel.close ();
dstChannel.close ();
return;
}
}
} catch (IOException e) {
}
}
}
Posted: 09 Apr 2007, 08:47
by LOrDo
Yes well, if you were to perhaps face reality, you would realize that most maps use sd7.
Good idea, Ive been thinking for a while that spring needs a program exactly like this, but its useless without support for sd7's.
Posted: 09 Apr 2007, 09:10
by Neddie
He never said most maps don't use sd7.
Posted: 09 Apr 2007, 09:28
by trepan
From the maps I have:
Code: Select all
> ls *.sd7 | wc -l
333
> ls *.sdz | wc -l
24
Posted: 09 Apr 2007, 10:41
by Tobi
TBH for the main Spring distribution we need such a tool which doesn't depend on big runtime environments.
Posted: 09 Apr 2007, 17:28
by AF
Dissing this tool because it doesnt have 7zip support is quite insulting, you should be happy you have anything at all rather than complaining you gained something but didnt gain more.
*he's £20! for free!!*
*Thats made of phail, there are such things as £50 notes, you suck*
However I dont agree that this requires such a big runtime environment, as the vasy majority of users already have a java runtime, and the majority of time spent running this tool is not occupied by java, but rather the batch script and the copying of the file which is a hardware limitation.
However this is a very small and simple programs. Adding sd7 support would be a matter of making a JNI binding to a 7zip dll (the program would no longer be crossplatform) or finding a 7zip java implementation.
For example, it wouldnt be hard to add a new .sdzai type that would extract the entire contents into the /AI/ folder, indeed the majority of the code could be pinched off of google.
Posted: 09 Apr 2007, 20:54
by LordMatt
AF wrote:Phail
The Dev team is not forced to include a tool just because it was written. Particularly when users seem to manage okay as it is without it.
Posted: 09 Apr 2007, 20:59
by Caradhras
i think its not usable yet, but every great thing begins little.
But if the lib, AF mentioned, is integrated or even coded, it should be something handy.
Posted: 09 Apr 2007, 21:08
by trepan
In AF's defense, I don't think he stated that he expects the tool to
be included in release packages. I can understand why he'd lash
back at having his work called "useless" (although the term "less
then ideal" certainly applies given the popularity of sd7 archives).
I've written the same thing using the minizip and 7zip libraries
that are already included in the Spring sources. It does not
require any external libraries (some of us don't have java
installed, and see no need to do so). It should work on all
platforms supported by Spring. The only part I haven't done is
smart detection of where the files should be moved to.
P.S. I suggest that AF keep his reaction in mind when making
posts about other devs' work in the future
Posted: 09 Apr 2007, 21:13
by Caradhras
As I read, AF is currently writing a client and server solution for CE, so you will perhaps install java someday.
But i agree to the point, that he should think about his reaction
Posted: 10 Apr 2007, 00:54
by Licho
What is CE?
Posted: 10 Apr 2007, 01:28
by jcnossen
The only thing i would suggest is adding a link to the JRE download in the readme, because sun's site is so phail. Ok maybe I'm just lazy, but most people are i think...
Posted: 10 Apr 2007, 20:21
by Caradhras
OSRTS -> Command Engine
Posted: 10 Apr 2007, 23:39
by Licho
Ahh, ok .. I hope the new lobby client and server are not going to be in java though :)
Well I dont care about server, but lobby should be in something faster and less memory hungry.