X Plugin Manager V2.12 : Updated 23/01/2010 *LINUX VERSION AVAILABLE*

[Stevio]

i am getting a 404 on the second Self extracting file

and the rest are saying "error can't find website ERROR:500"
perhaps because everyones trying to download it at once???

[Naffarin]

Hmm, what would you think if the uninstallation procedures are not packaged with the script package but a different package that could be installed and uninstalled?
It would make additional handling unnecessary in the script installer and we don't need a separate directory for it.

Would be a simple but working solution i think.

[Naffarin]

I have another suggestion

Autogenerate the package file name, consisting of package name, version number and date of creation. Could be a separate button if someone doesn't like the generated format.

[Cycrow]

i am getting a 404 on the second Self extracting file

and the rest are saying "error can't find website ERROR:500"
perhaps because everyones trying to download it at once???

my fault, i only copied the rar file to the server
should work now

Hmm, what would you think if the uninstallation procedures are not packaged with the script package but a different package that could be installed and uninstalled?
It would make additional handling unnecessary in the script installer and we don't need a separate directory for it.

Would be a simple but working solution i think.

You have by having 2 script packages, one holds the script, and the other holds the uninstall scritps ?

so the user has to install the uninstall package for it to work ?
if the packages are set with the same name and author, the installer will automatically uninstall the current one b4 installing the new one, so it could uninstall the current script and install the uninstall script files, althou seems abit more hassle for the use than letting the installer do it all for you

I have another suggestion

Autogenerate the package file name, consisting of package name, version number and date of creation. Could be a separate button if someone doesn't like the generated format.

Yeah i like that, would make things abit easier, but if the name of the script is long, it could make quite a long filename, ie "Bounty Hunters Guild 2.52 10/1/2006.spk"

althou that does remind me, i should add the data into the packager too

[Stevio]

i am getting a 404 on the second Self extracting file

and the rest are saying "error can't find website ERROR:500"
perhaps because everyones trying to download it at once???

my fault, i only copied the rar file to the server
should work now

thanks

[Kilrathi Avenger]

Fantastic
This could turn out to the the most important addon/script to date especially for all the noobs out there. I.E. me!!!

Can't wait until version 1 released.
Hopefully this will become the standard method for distribution/installation of scripts
Thanks Cycrow have all your scripts Keep up the first class effort

[A dJ]

Hmm, another suggestion
for Installer: ability to add packages to the list first install later.

[Cycrow]

Hmm, another suggestion
for Installer: ability to add packages to the list first install later.

im gonna add the option to enable and disable scripts, so u can diable the script without having to uninstall it

[X-it]

Another great idea put to practise, nice. Used a similar program for Silent Hunter III mods, called 'Mod enabler'.

I know you're a scriptin' kind of guy , but how about a similar program for mods as well, or include it in this one? It could automatically rename the .dat and .cat files to a number higher than the highest already present i the main X3 folder, and rename them something else if you want a mod disabled.

Not too much work to manually rename those files, but like this it would be handy for newbies and lazy ones like me...

Anyway, thanks for this!

[999-JAY-999]

Praise be the Cycrow..... JUST what the doctor ordered.


At last....... a good time to wipe out my script and t directories and start a fresh install...

[Burianek]

Uninstall is going to be tricky. Every script has a slightly different uninstall procedure depending on the script. Like Naffarin says, he must use a seperate script to uninstall that scans stations and removes wares or something of that nature. You can't be expected to provide for all that flexibility.

If you want my advice .. don't call the button uninstall. Simply call it 'remove script files'. (and put a disclaimer that hitting this button may or may not uninstall the script, see script readme for details) If you call it uninstall this thread is immediately going to get flooded with 'WTF?!! I hit the uninstall button, but I still have all these readtexts in my game?!?! Test your $%#&% installer before you realease it in an unfinished state jerk! ' heh.

Then the individual authors can work that into their uninstall procedure that they spell out in the readme. You know what I mean? Most scripts uninstall instructions might look like:

Uninstall:
- Stop all ships from running the blah blah command in game.
- Save your game and exit.
- Run the installer's 'remove script files' command for this script.

Naffarin's uninstall instructions might throw in the extra steps of:
- use the installer to install the 'Naffarin cleanup script'. (or something, which puts his uninstall setup script in the directory)
- Load the game, wait ten seconds, and resave.
- Run the installer's 'remove script files' command for the 'Naffarin cleanup script'.

You see what I mean? By not trying to do too much, it has the flexibility to do everything.

The thing your program can do (which is nice) is remove the correct files from the scripts directory. That's one of the big questions that I see a lot on the forums is 'it told me to remove the scripts from my /scripts directory, but I don't know which is which'.

Another piece of advice, when you do remove script files, only remove setup scripts (I guess check for init too, but those are bad practice). It will never hurt anything to leave the rest of the scripts in the folder. Without a setup script, they'll never be run. This avoids the problem of shared files between packages. Like if a guy uses the same /t file for several scripts or has a few lib.whatever.xml scripts that he uses across packages.

Just a few comments, I'm sure this will help out a ton.

[Cycrow]

yes, i think its a good idea to say remove scritps files instead, would stop some of the complaints at least

as for the shared files, the program can actaully handle shared files, cuz you can set which files wil be shared, and these arn't removed

[argharg]

I command Cycrow for trying to put some order in the 100's of scripts files I am using atm. I hope LV and RS will endorse the project as well.

[Cycrow]

New update

V0.91
* Added Compression to package files
* Added Readme into packages
* Added Default directory for Script Packager
* Added Date
* Added Auto Save

[NZ-Wanderer]

Ohh very very nice...

Gonna have to use this to do all the scripts I have installed.. - will save a lot of time later methinks...

Thank you for supplying this to the community

[nuclear_eclipse]

Does this program have a way of determining whether a script package is trying to install an older version over a newer version? It might be nice to check the actual script xml <codearray> section to see what the actual script says its version is, then go on that to decide to install it or not. If you need help looking for the code version inside the scripts, give me a hollar on AIM/ICQ/PM, and I'll let you know all you need to know...

[Cycrow]

no, it doesn't check that yet
i could just add a header to the file which cant be read to get the version number, but i havn't done that yet

[nuclear_eclipse]

no, it doesn't check that yet
i could just add a header to the file which cant be read to get the version number, but i havn't done that yet

It wouldn't be too difficult to read directly from the script's codearray, and I think it would be far more usefull to do so than to use a proprietary means of version tracking. But alas, that is my own opinion...

[Cycrow]

ah yes, i c what you mean

so it checks the individual script file version and only installs those of a newer version ?

[nuclear_eclipse]

ah yes, i c what you mean

so it checks the individual script file version and only installs those of a newer version ?

Exactly. It would read in a very similar manner to how my external script editor reads the codearray. Just search for certain markers, and voila, you have your script version. This way, it would go by what the script maker marks his versions ingame with. And if th escripter took advantage of the script commands to check for newer versions, then it would incredibly usefull and powerful.