X Plugin Manager V2.12 : Updated 23/01/2010 *LINUX VERSION AVAILABLE*
Moderators: Moderators for English X Forum, Scripting / Modding Moderators
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.
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.
"Nature's first green is gold" . . . stay golden.
Update v0.91
New update
V0.91
* Added Compression to package files
* Added Readme into packages
* Added Default directory for Script Packager
* Added Date
* Added Auto Save
V0.91
* Added Compression to package files
* Added Readme into packages
* Added Default directory for Script Packager
* Added Date
* Added Auto Save
- NZ-Wanderer
- Posts: 1623
- Joined: Thu, 5. Aug 04, 01:57
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
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
Link to the list of Mods working in X4-Foundations and also Link to the list of Mods working in X-Rebirth
NOTE: I play with a modded game, so any reports I make outlining suggestions/problems/bugs/annoyances, are made with mods installed and running.
NOTE: I play with a modded game, so any reports I make outlining suggestions/problems/bugs/annoyances, are made with mods installed and running.
- nuclear_eclipse
- Posts: 1129
- Joined: Thu, 2. Sep 04, 01:54
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...
- nuclear_eclipse
- Posts: 1129
- Joined: Thu, 2. Sep 04, 01:54
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 wrote: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
- Posts: 1129
- Joined: Thu, 2. Sep 04, 01:54
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.Cycrow wrote:ah yes, i c what you mean
so it checks the individual script file version and only installs those of a newer version ?
- NZ-Wanderer
- Posts: 1623
- Joined: Thu, 5. Aug 04, 01:57
Yea, unless the script maker forgot to update the version number in the script.. - so you would have to probably have it so it replaced same version numbers or it wouldn't get updated.
nuclear_eclipse wrote: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.
Link to the list of Mods working in X4-Foundations and also Link to the list of Mods working in X-Rebirth
NOTE: I play with a modded game, so any reports I make outlining suggestions/problems/bugs/annoyances, are made with mods installed and running.
NOTE: I play with a modded game, so any reports I make outlining suggestions/problems/bugs/annoyances, are made with mods installed and running.
Update 0.92
New update to the packager
V0.92
* (Packager) Added "New Package" command
* (Packager) Added save commands to file menu
* (Packager) Added Default Destination directory
* (Packager) Added package scripts, for easy creation of package files
You can create a simple script which can be used to easily setup your package file.
The script is just a text file, and can either have the file extensions of .txt or .sps
Once you have created the script file, you goto the "File" menu and select "Load Package Script" then select the script file
you created.
This will set the script settings as well as add all the files.
This is an example script. Each line has a different instruction, the first word is the command, IE "Name:"
The commands that are currently available:
Name: - Sets the name of the script
Author: - Sets the author of the script
Date: - Sets the date of the script
Version: - Sets the Version for the script
Script: - Loads in a script file, can use wildcards
SharedScript: - Same as Script:, but sets the file as shared
Text: - Loads in a text file (t file), can use wildcards
SharedText: - Same as Text:, but sets the file as shared
Readme: - Loads in a readme file, can use wildcards
V0.92
* (Packager) Added "New Package" command
* (Packager) Added save commands to file menu
* (Packager) Added Default Destination directory
* (Packager) Added package scripts, for easy creation of package files
You can create a simple script which can be used to easily setup your package file.
The script is just a text file, and can either have the file extensions of .txt or .sps
Once you have created the script file, you goto the "File" menu and select "Load Package Script" then select the script file
you created.
This will set the script settings as well as add all the files.
Code: Select all
Name: Bounty Hunters Guild
Author: Cycrow
Script: D:\Games\X3\Scripts\al.plugin.bountyguild.xml
Script: D:\Games\X3\Scripts\al.bountyhunt.*
SharedScript: D:\Games\X3\Scripts\lib.cycrow.*
SharedText: D:\Games\x3\t\447532.xml
SharedText: D:\Games\x3\t\497532.xml
Readme: D:\Games\X3\MyScripts\BH-X3\Readme\bh-readme.txt
The commands that are currently available:
Name: - Sets the name of the script
Author: - Sets the author of the script
Date: - Sets the date of the script
Version: - Sets the Version for the script
Script: - Loads in a script file, can use wildcards
SharedScript: - Same as Script:, but sets the file as shared
Text: - Loads in a text file (t file), can use wildcards
SharedText: - Same as Text:, but sets the file as shared
Readme: - Loads in a readme file, can use wildcards
-
- Posts: 622
- Joined: Mon, 7. Apr 03, 16:29
ok...let me get my head around this.
To make a package from a decompressed script... so I can install it through this program I need to do the following ...
Scripts... attach and select all script files from the SCRIPT DIRECTORY (is there a way to select ALL in one key press?)
Then do I select all text files from the T directory ???
Then make the package ???
To make a package from a decompressed script... so I can install it through this program I need to do the following ...
Scripts... attach and select all script files from the SCRIPT DIRECTORY (is there a way to select ALL in one key press?)
Then do I select all text files from the T directory ???
Then make the package ???
System Spec :-
AMD Athlon(tm) 64 Duel 6000+ (3.01GHz)
Windows XP Home Ed. SP 3
ATI Radeon HD 4850 (512)
Creative X-FI Soundard
2.00 GB of RAM
G9 RAZOR Mouse
AMD Athlon(tm) 64 Duel 6000+ (3.01GHz)
Windows XP Home Ed. SP 3
ATI Radeon HD 4850 (512)
Creative X-FI Soundard
2.00 GB of RAM
G9 RAZOR Mouse
thats one way to do it yeah
and yes you can select the files, u either hold down ctrl and select each individual script
or ucan use shift, u select the first script, hold shift and select the last script, and it selects all the files between them, u can also use a combination of both
but basically what you do, is add the script files, then add the text files, then the readme
in the newest version, u can also write a simple script to do it for u, basically using wildcards to set the files, u just load that script and it creates the package for u
if using wildcards in the script, then u only have to edit the script once, and u can load it to create the package for each new version
and yes you can select the files, u either hold down ctrl and select each individual script
or ucan use shift, u select the first script, hold shift and select the last script, and it selects all the files between them, u can also use a combination of both
but basically what you do, is add the script files, then add the text files, then the readme
in the newest version, u can also write a simple script to do it for u, basically using wildcards to set the files, u just load that script and it creates the package for u
if using wildcards in the script, then u only have to edit the script once, and u can load it to create the package for each new version
Update 0.93
Another update
V0.93
* (Installer) Added library file tracking
* (Installer) Records versions numbers of each script file
* (Installer) Added View Scripts Files
* (Installer) Added View Shared Files
Getting close to the release version, so i would like to know if anyone found any bugs so i can fix them b4 the release version
V0.93
* (Installer) Added library file tracking
* (Installer) Records versions numbers of each script file
* (Installer) Added View Scripts Files
* (Installer) Added View Shared Files
Getting close to the release version, so i would like to know if anyone found any bugs so i can fix them b4 the release version
I am not sure if it could be called a bug, but i noticed that an uncompressed version of the script archive is created in the directory where the compressed archive is.
I think it could be deleted after extracting the script contents.
It happened when i retested installing a script from a different directory than the x3 directory.
I used the following scenario:
Compressed script package: D:\temp\StationTrader-V1.22-16.01.2006.spk
X3 directory: D:\games\x3
After installing the scripts there was a file d:\\temp\StationTrader-V1.22-16.01.2006
I think it could be deleted after extracting the script contents.
It happened when i retested installing a script from a different directory than the x3 directory.
I used the following scenario:
Compressed script package: D:\temp\StationTrader-V1.22-16.01.2006.spk
X3 directory: D:\games\x3
After installing the scripts there was a file d:\\temp\StationTrader-V1.22-16.01.2006