Beta-testing: tool to quickly activate/deactivate OXPs

[GGShinobi]

WARNING: PLEASE READ DISCLAIMER FOUND AT THE END OF THIS POST BEFORE USING THIS!

Hi folks,

I've got nearly 300 OXP's installed, and I often have to temporarily deactivate them for testing purposes. What I did to achieve this was:

• create a folder (e.g. ~/Desktop/OXPs/) for the oxp's I temporarily want to disable
• select all unwanted oxps from the oolite-AddOns folder
• move them to the new folder

re-enabling them was quicker, since I only needed to move ALL files from the temporary folder back to Oolite's AddOns-Folder.

But for some (unknown) reason, doing this with my filemanager (nautilus) took a considerable amount of time, and since I'm also more a keyboard user than a mouse user I wanted a quicker way. Doing it with bash-commands was a little unwieldy, though, so I wrote a shell-script to support me. If you are interested, you can download the script from my box: https://www.box.com/s/un6niaity1cmgjpl7nj5

Here is the usage:

Code: Select all

=============================================================================
activate or deactivate oxps by moving them from/to another directory (holding track).
This hopefully speeds up the lenghty process of moving the AddOns for tests.
[IMPORTANT INFO:] It is STRONGLY recommended to set the masterdirectories so that they
                   are located inside the same volume/filesystem, or else
                   the moving of the oxps will take much, much  longer!
[-=notes=-]:
 - this will create a holding track directory if it doesn't exist yet. The dirs used may be specified in the script:
   AddOns: '/home/ggshinobi/.Oolite/AddOns'
   AddOnsHoldingTrack: '/home/ggshinobi/.Oolite/AddOnsHoldingTrack'
 - spaces in oxp-names are not allowed. If you have oxps with spaces, convert their names:
   OLDIFS="$IFS"; IFS=$'\n'; for x in `ls -1 | grep "[[:space:]]"`; do mv $x ${x// /_}; done; IFS="$OLDIFS"
[-=usage=-]:
addOnsManage.sh [-i] <mode> [oxp1] [oxp2]...
  -i: case insensitive search
  <modes>:
    -a / activate: activate the given oxps by moving them into the specified AddOns-Folder
    -d / deactivate: deactivate the given oxps by moving them to the specified HoldingTrack-Folder
    -aa / activateAll: activate all oxps which are available in AddOnsHoldingTrack/
    -da / deactivateAll: deactivate all oxps (move all from AddOns/ to AddOnsHoldingTrack/)
      note: for activateAll and deactivateAll, no further parameters are allowed! (sanity check)
    -si / showInstalled: show installed / activated oxps
    -sa / showAvailable: show oxps available for activation / installation
      The showModes will use any parameters to further filter results through case-insensitive grep.
[-=examples=-]:
  addOnsManage.sh -a Updating_TSC_1.5.1.oxp Snoopers2.4.oxp/
  addOnsManage.sh -i -a planet our # will for instance activate PlanetaryCompass, PlanetFall, YOUR-ADD-HERE, tesoura...
  addOnsManage.sh -aa
  addOnsManage.sh -si updat snoop # will show all installed oxps containing either updat or snoop (case-sensitive)
  addOnsManage.sh -i -si updat snoop # will show all installed oxps containing either updat or snoop (case-insensitive)
[-=hints=-]:
 - you don't need to specify the exact name. It suffices if the string you provided matches.
 - the more precise you type the names of the oxp's, the less will be selected.
 - if you enter (de)activate mode without specifiying oxp's, you will be prompted to enter them.
   This prompt should support parameter expansion (if it is set on your system).
 - case-sensitive search is the default. Use -i as first parameter to use case-insensitive search.
=============================================================================

DISCLAIMER:
Please note that I tested it and it works well for me. It also contains several sanity checks, but after all, you use it on your own risk! So I very strongly recommend to backup your AddOns-Folder before using this!
EDIT: I also strongly suggest that you make sure the scripts' "master directories" are configured so that they are on the same volume. Else, the files would have to be physically copied and removed each time (instead of just modifiying their i-nodes, which is very quick).
EDIT2: Uploaded a new version (identical in operation) which more explicitly points out that the master directories should reside on the same volume / filesystem. Updated the code snippet (that shows the usage).

[Diziet Sma]

Very impressive. It certainly beats the hell out of my bash-scripting abilities.


If I may, however, (and not to knock your work at all) I use what I believe is a simpler and safer method which has the added benefit of being faster and putting less workload on the hard-drive. I've been meaning to post it anyway, and this thread seems a suitable place. Proceed as follows:

• Rename AddOns to MainAddOns
• Create another folder named TestingAddOns
• Create a link/shortcut to MainAddOns
• Rename the link/shortcut to AddOns
• Create a link/shortcut to TestingAddOns
• Rename the link/shortcut to TestAddOns
• Copy the OXPs you wish to use for testing into TestingAddOns. You can leave a 'core' set of OXPs such as a Config folder, your favourite HUD and equipment OXPs, etc, in there, and add individual OXPs for testing as required.

Here's the above setup in place on my machine. Obviously, if you keep your AddOns in another location, it won't look quite the same.




Now, create the following bash-script. Naturally, if your AddOns folder is in a different location, you will need to adjust the paths to suit. Save it as 'swapaddons'. Make the file executable and place it in your personal 'bin' folder in your home directory. (Anything in 'bin' is automatically in your path. This means you won't have to prefix the command with './') If you don't have a 'bin' folder, just make one and drop the 'swapaddons' script into it.

Code: Select all

#!/bin/sh
if test -f ~/GNUstep/Applications/Oolite/TestAddOns
then
	mv ~/GNUstep/Applications/Oolite/AddOns ~/GNUstep/Applications/Oolite/TempName
	mv ~/GNUstep/Applications/Oolite/TestAddOns ~/GNUstep/Applications/Oolite/AddOns
	echo "Switched to Testing AddOns"
else
	mv ~/GNUstep/Applications/Oolite/AddOns ~/GNUstep/Applications/Oolite/TestAddOns
	mv ~/GNUstep/Applications/Oolite/TempName ~/GNUstep/Applications/Oolite/AddOns
	echo "Switched to Main AddOns"
fi
exit $?

Now, any time you want to swap from one set of AddOns to the other, you simply type 'swapaddons' into a terminal. It will automatically change from one to the other. Typing 'swapaddons' a second time will switch things back the way they were. A message will be displayed in the terminal to let you know which AddOns folder is now active. Now start Oolite, and it will automatically use the correct set of AddOns.

And the only drive-activity involved is the renaming of two shortcuts whenever you execute the script!

[GGShinobi]

Very impressive. Beats the hell out of my bash-scripting abilities.

Thanks for that compliment!

I use what I believe is a simpler and safer method which has the added benefit of being even faster and putting far less workload on the hard-drive.

That's right. Although my solution is also very fast (as long as both used directories reside on the same volume! If not ... VEEERY BAD! ) your solution is even faster!

And the only drive-activity involved is the renaming of two shortcuts whenever you execute the script!

I think you've found a very elegant solution! I might have better bash-scripting abilities, but as your example shows, you still beat me on finding a simpler solution! My compliments!

The only flaw I see is that I've found a typo in your bash script:

~/GNUstep/Applications/Oolite/MnAddOns
I believe this should be "MainAddOns" But as I said: very elegant your solution!

[Diziet Sma]

Thank you for the kind compliments!

The only flaw I see is that I've found a typo in your bash script:

~/GNUstep/Applications/Oolite/MnAddOns
I believe this should be "MainAddOns" But as I said: very elegant your solution!

Actually, I went back and edited the post to explain that. It's actually very important that it NOT be "MainAddOns" as that folder already exists. If you attempt to rename the shortcut to "MainAddOns" it will fail, as that file already exists. "MnAddOns" is a temporary "holding" name, until you change back to normal.

For the same reason, the shortcut for TestingAddOns is renamed to TestAddOns. If this isn't done, the script would encounter an error when it attempts to rename the AddOns shortcut to TestingAddOns, as a folder with that name already exists.

Edit: I've gone back and altered the script so that it is clearer that a temporary holding name is in use. Instead of "MnAddOns" it is now "TempName".

[Smivs]

I just wanted to compliment you both for being so complimentary!

[GGShinobi]

Thank you for the kind compliments!

The only flaw I see is that I've found a typo in your bash script:

~/GNUstep/Applications/Oolite/MnAddOns
I believe this should be "MainAddOns" But as I said: very elegant your solution!

Actually, I went back and edited the post to explain that. It's actually very important that it NOT be "MainAddOns" as that folder already exists. If you attempt to rename the shortcut to "MainAddOns" it will fail, as that file already exists. "MnAddOns" is a temporary "holding" name, until you change back to normal.

For the same reason, the shortcut for TestingAddOns is renamed to TestAddOns. If this isn't done, the script would encounter an error when it attempts to rename the AddOns shortcut to TestingAddOns, as a folder with that name already exists.

Oh I see! My fault then. Didn't use my brain enough to see that, since I thought I already got the idea! Sorry for the false alarm!

I just wanted to compliment you both for being so complimentary!

Oh, thank you Smivs, very kind of you!
It seems the friendliest Gourd in the galaxy is recovering well! Good to see that!

[Diziet Sma]

I just wanted to compliment you both for being so complimentary!

Heck.. GGShinobi is waaaayy ahead of my poor skills.. I'm just very thankful that he didn't mind me stealing his thunder.

[Thargoid]

Another method is just to rename the <oxpMainFolder>.oxp folder to <oxpMainFolder>.disabled (ie remove the .oxp from the end, and optionally replace it with .disabled to make it more obvious that it's not active). If the folder doesn't end in .oxp then the game will ignore it and anything that's inside it.

Also the search is recursive, so if you have a folder unstable.oxp containing all your under test OXPs (each within their own .oxp name-ended subfolder), you can quickly deactivate the whole lot by renaming the umbrella unstable.oxp folder. And file/folder renaming is quicker than moving things about (usually).

[Diziet Sma]

Where that gets a pain is when you wish to also disable certain OXPs before testing. You need to move or rename them. Having dual AddOns folders lets you keep a separate set tailored to your testing needs without messing with your everyday playing set. And I can type 'swapaddons' faster than I can rename even one folder, let alone two..

[GGShinobi]

I just wanted to compliment you both for being so complimentary!

Heck.. GGShinobi is waaaayy ahead of my poor skills.. I'm just very thankful that he didn't mind me stealing his thunder.

LOL

Another method is just to rename the <oxpMainFolder>.oxp folder to <oxpMainFolder>.disabled (ie remove the .oxp from the end, and optionally replace it with .disabled to make it more obvious that it's not active). If the folder doesn't end in .oxp then the game will ignore it and anything that's inside it.

Also the search is recursive, so if you have a folder unstable.oxp containing all your under test OXPs (each within their own .oxp name-ended subfolder), you can quickly deactivate the whole lot by renaming the umbrella unstable.oxp folder. And file/folder renaming is quicker than moving things about (usually).

Hey, another fine way to do it! Thanks Thargoid (I love your name, did I mention that? )
I didn't think about that (although I should've known it, because once I had the problem that I extracted some oxp.zip into the AddOns-folder but the oxp didn't run because the .oxp-folder was hidden inside another folder)

[GGShinobi]

Where that gets a pain is when you wish to also disable certain OXPs before testing. You need to move or rename them. Having dual AddOns folders lets you keep a separate set tailored to your testing needs without messing with your everyday playing set. And I can type 'swapaddons' faster than I can rename even one folder, let alone two..

Diziet Sma surely has a point there. But for my approach, simply renaming the oxp-directories (by appending ".disabled" to them) would have been a good solution, since it would make sure that the directories remain on the same volume. But I'm too lazy to upgrade my script now. Will leave that to someone else I wanna inspect Thargoids Cargo Spotter and the LongRangeScanner and AWACS oxp's now (to gather knowledge for my Long Range Scanner).