On the latest dev build I've got (it's about 20 or 30 revisions behind already mind you), I can't for the life of me figure out how to arrange the directory structure for SDD files.
Could someone please post an example directory/zip tree for me to look at?
Thanks for implementing my idea so quickly, btw! This'll make AA installs MUCH, MUCH cleaner.
How to use SDD
Moderator: Moderators
SDD files arent files at all, they're folders think SDZ == spring data zip SDD = spring data directory.
The contents of an SDD are identical to the contents of an SD7, only they're in a folder not an archive.
aka
/mods/AA.SDD/mod_info.tdf
/mods/AA.SDZ with mod_info.tdf inside.
Look at jelmers dev build releases with sm3 maps, as some of the ones he made use sdd ratehr than sdz/7
The contents of an SDD are identical to the contents of an SD7, only they're in a folder not an archive.
aka
/mods/AA.SDD/mod_info.tdf
/mods/AA.SDZ with mod_info.tdf inside.
Look at jelmers dev build releases with sm3 maps, as some of the ones he made use sdd ratehr than sdz/7
hmm, you'll encounter the problems I encountered with installers, namely people asking where to extract the rar archive too oblivious to the fact its actually containing an installer, all the while, you think they're asking where to install to.
All caused by the file hosting sites not accepting .exe's
I found that a lot of it can be avoided easily. Hence why the archive I uploaded is now named NTaiInstaller.rar not NTaiXE9RC22.rar
All caused by the file hosting sites not accepting .exe's
I found that a lot of it can be avoided easily. Hence why the archive I uploaded is now named NTaiInstaller.rar not NTaiXE9RC22.rar
It may need a bit less CPU while loading because there's no need to decompress anything, but it uses significantly more diskspace (decompressed data plus overhead because of file system's resolution (4k blocks for all filesystems I know).
This means CPU usage may be reduced, but disk IO is probably increased a LOT (esp. if all these many small files are fragmented over the disk while extracting them).
Also keep in mind that e.g. zip is very fast to decompress, so I wouldn't really recommended distributing everything in self extractable .sdd files.
Then I don't even talk about requiring user to perform an extra error-prone step after downloading the file. (e.g. now it's drop in & play, then it's drop in, extract & play.)
E: note that I developed those archives mostly for development purposes: so you can keep around multiple mods in extracted form in your spring directory.
This means CPU usage may be reduced, but disk IO is probably increased a LOT (esp. if all these many small files are fragmented over the disk while extracting them).
Also keep in mind that e.g. zip is very fast to decompress, so I wouldn't really recommended distributing everything in self extractable .sdd files.
Then I don't even talk about requiring user to perform an extra error-prone step after downloading the file. (e.g. now it's drop in & play, then it's drop in, extract & play.)
E: note that I developed those archives mostly for development purposes: so you can keep around multiple mods in extracted form in your spring directory.
As long as it are self extracting 7zips it would work I think.AF wrote:It always forces non windows users to handle the issue of trying to execute a .exe installer on a non windows system.
My 64 bit linux 7z binary is capable of creating & extracting 32 bit windows 7z .exe's IIRC
But you're right, anything else wouldn't work, and most linux users probably don't know they can extract a 7z self extracting .exe on linux, so they wouldn't even try...
7zip has a crappy compression routine similar to Ace files though. even if all yoru need is that one txt file,it needs to extract the whole archive to get it. so with a huge 7z file the computer will be workign a long time uncompressing data you don't need to a dumping temp folder, to get the one file.KDR_11k wrote:With most modern programs you just drag and drop the file you have changed and only that gets recompressed...
Unless they've majorly restructured and rewrote the algorithm recently, very recently
-
el_matarife
- Posts: 933
- Joined: 27 Feb 2006, 02:04
If you turn solid archive mode off, this doesn't happen. Solid mode is implemented into 7Zip because it improves the compression ratio if you use a lot of similar files by treating all the files as one large data stream. If you turn this option off when you create an archive, the compression ratio may get worse but you can change or extract single files in an archive easier.7zip has a crappy compression routine similar to Ace files though. even if all yoru need is that one txt file,it needs to extract the whole archive to get it.
Don't forget the F8 save function. It doesn't work perfectly but it saves you the .cheat .give .give .give .give .give ....Gnome wrote:It's still way easier to use sdd. Sdd plus spring.exe's ability to choose mods itself a couple versions ago means it's finally a breeze to test mods. I've been using it since the dev build was put out, and there's no way I could go back now!
This isn't necessarily true. AA uses uncompressed ZIPs inside a highly compressed ZIP (the distro package with readmes, URLs, etc), meaning virtually no load time.Argh wrote:That is going to rock soooooo hard. We'll be able to distro our mods as self-extracting 7z's... and users will no longer have to wait for the mods to decompress before the next steps of loading the game starts. The overall benefits in terms of speed should be very nice.
~~~
Hmm... Can't get it to work. I put my Patch file dependancy to "AASBASE.SDD", and put a folder in my mods directory called "AASBASE.SDD". Then I dump the contents of AASBASE.SDZ into it... and it crashes.
Says it can't find gamedata/movinfo.tdf, and also the background pic doesn't show, so it's not finding the directory. I'm sure I must be doing something so obvious wrong. Or maybe SDDs can't be used as a dependancy? Anyone?
AASP22.SDZ:
Code: Select all
[MOD]
{
Name=Absolute Annihilation 2.2 Patch Data;
NumDependencies=1;
Depend0=AASBase22.sdd;
}