Welcome to Open Carnage

A resource for Halo Custom Edition and MCC modding, with unique means of rewarding content creation and support. Have a wander to see why we're worth the time! - EST. 2012

Zatarita

Regular
  • Content count

    176
  • Joined

  • Last visited

  • Raffle Tickets

    0

Reputation Activity

  1. Zatarita liked a post in a topic by Halo_hogger in Motion Capture Tutorial For Halo Custom   
    Detailed tutorial on how to create and implement motion captured animations into your halo ce creations. 
  2. Tucker933 liked a post in a topic by Zatarita in unpck - pck extractor   
    Bug fix for pckref.
    If you're having trouble, redownload
     
    Fixed offsets not being set correctly
  3. tarikja liked a post in a topic by Zatarita in unpck - pck extractor   
    pckref
     
    I made another program using the same library set I decided to just bundle together.

    pckref is another cli style tool that can add refrences to decompressed pcks. Letting you inject textures and templates across the game. given you have the tag in there already. eg brute on cairo



    Usage is fairly simple


    You simply type the pack you want to edit enter the new references you want to add, and any additional flags.
     
    To find the references, it's easiest to use the csv they included with each pck.
     


    download: https://github.com/Zatarita/SeT-CPP/raw/main/bin/Release/pckref.exe
  4. tarikja liked a post in a topic by Zatarita in unpck - pck extractor   
    pckref
     
    I made another program using the same library set I decided to just bundle together.

    pckref is another cli style tool that can add refrences to decompressed pcks. Letting you inject textures and templates across the game. given you have the tag in there already. eg brute on cairo



    Usage is fairly simple


    You simply type the pack you want to edit enter the new references you want to add, and any additional flags.
     
    To find the references, it's easiest to use the csv they included with each pck.
     


    download: https://github.com/Zatarita/SeT-CPP/raw/main/bin/Release/pckref.exe
  5. tarikja liked a post in a topic by Zatarita in unpck - pck extractor   
    pckref
     
    I made another program using the same library set I decided to just bundle together.

    pckref is another cli style tool that can add refrences to decompressed pcks. Letting you inject textures and templates across the game. given you have the tag in there already. eg brute on cairo



    Usage is fairly simple


    You simply type the pack you want to edit enter the new references you want to add, and any additional flags.
     
    To find the references, it's easiest to use the csv they included with each pck.
     


    download: https://github.com/Zatarita/SeT-CPP/raw/main/bin/Release/pckref.exe
  6. Tucker933 liked a post in a topic by Zatarita in H2A - pct format   
    With the release of unpck I feel it's a good time to give a more technical update on some h2a progress being made.
     
    to see these files we'll need to decompress, and extract a pck file for h2a,

    The format we're looking at today is located inside of the shared.pck file. The file format pct is for textures. Unlike CEA, h2a textures are broken up into individual files. These are all dds textures with their header stripped, and a new saber specific header stitched on. The layout is very similar to the imeta/ipak format in cea. to locate these files, after extacting shared.pck, navigate to the textures folder inside the shared subdirectory. In this folder we see every texture used in the game. If we open them in a hex editor we'll see a header 0x3A bytes wide, and the rest is all pixel data.


    The format is a sentinel based system with delimiters for file type. Before we continue, I want to touch of this a bit.
    Each file is broken up into structured objects. these objects are given a number to represent what it is. When the engine encounters one of these objects, it knows to load the preceding data into that objects variables.
    The contents of the sentinel can vary depending on intended use; however, there will be at lease:
    short: number reference for object structure int32: Pointer to end of chunk ... the actual data the object holds ...
    The pct format is no different. I like to think of this as an unfolded c-style class.
    sentinel 0x00F0 (File header/signature) {     int32 end_of_block; string signature = "TCIP"; } sentinel 0x0102 (bitmap shape) { int32 end_of_chunk sint32 width, height, depth, faces; } sentinel 0x00f2 (dds format) { int32 end_of_block; pck_format type; (32 bit) } (See below for types) sentinel 0x00f9 (mipmap count) { int32 end_of_block; int32 mipmap count; } sentinel 0x00ff (pixel data) { int32 end_of_block; pixed_data; (the format changes depending on format type so this is pseudo-code) } sentinel 0x0001 (Footer) { int32 end_of_block }  

    Format types:
    The header holds the dds format. From what I can tell these are the ones that are used in game, though since saber uses their engine for many different games, I wouldn't be surprised if there were more. Been researching some of their other games to see what I can find as well. for now, just h2a:
     
    A8R8G8B8 - 0x00
    AI88 - 0x0A
    OXT1 - 0x0C
    AXT1 - 0x0D
    DXT3 - 0x0F
    DXT5 - 0x11
    X8R8G8B8 - 0x16
    DXN - 0x24
    DXT5A - 0x25
    A16B16G16R16 0x26
    R9G9B9E5_SHAREDEXP, 0x2D
     
    wrapping all this together we have the entire block defined. I like to see things visually to help get a better grasp:

    All things in green are sentinels
    All things in blue are end of blocks.
    Orange is the header
    Yellow is bitmap dimensions, and face count
    Pink is format
    Purple is mipmap count
    White is pixel data

    here is also the footer. It is just a sentinel and end of block (or in this case end of file) with no extra data.


    Applied looks like this:

  7. Zatarita liked a post in a topic by Sunstriker7 in unpck - pck extractor   
    One of the best software names I've ever seen.
  8. Tucker933 liked a post in a topic by Zatarita in unpck - pck extractor   
    unpck is a cli style program that unpacks decompressed pck files. a-sdk hasn't had compression implemented yet.
    Usage is simple
    "unpck <filename>"
    if you're trying to unpack the shared.pck you need to use the -s flag
    "unpck <filename> -s"
    it will create a new folder in the pck's directory with the pck's name, and inside it will create the subdirectories and them extract the data.
    This is the first tool build with the a-sdk library, and there may be some minor tweaks needed to be done.
     
    THE PCK FILES NEED TO BE DECOMPRESSED.
    to decompress the file:
     

     
    Note the file names needed to be sanitized due to forbidden characters being used in the file name internally (EG <scene>/tpl/01a_tutorial.cdt gets sanitized to _scene_/tpl/0a1_tutorial.cdt)
     
     
    source: https://github.com/Zatarita/SeT-CPP
    download: https://github.com/Zatarita/SeT-CPP/raw/main/bin/Release/unpck.exe
    Bug squashed a bit, completely rewrote the unpcker and linked everything static. Seems everything is working a bit better. Added shared.pck support using the -s flag
     

  9. Tucker933 liked a post in a topic by Zatarita in unpck - pck extractor   
    unpck is a cli style program that unpacks decompressed pck files. a-sdk hasn't had compression implemented yet.
    Usage is simple
    "unpck <filename>"
    if you're trying to unpack the shared.pck you need to use the -s flag
    "unpck <filename> -s"
    it will create a new folder in the pck's directory with the pck's name, and inside it will create the subdirectories and them extract the data.
    This is the first tool build with the a-sdk library, and there may be some minor tweaks needed to be done.
     
    THE PCK FILES NEED TO BE DECOMPRESSED.
    to decompress the file:
     

     
    Note the file names needed to be sanitized due to forbidden characters being used in the file name internally (EG <scene>/tpl/01a_tutorial.cdt gets sanitized to _scene_/tpl/0a1_tutorial.cdt)
     
     
    source: https://github.com/Zatarita/SeT-CPP
    download: https://github.com/Zatarita/SeT-CPP/raw/main/bin/Release/unpck.exe
    Bug squashed a bit, completely rewrote the unpcker and linked everything static. Seems everything is working a bit better. Added shared.pck support using the -s flag
     

  10. tarikja liked a post in a topic by Zatarita in SeT team - progress   
    So, I finally did my first build of what I'm now calling the anniversary SDK or A-sdk for a pck unpacker. It works for everything except shared.pck. I need to write a light weight handler that doesn't load everything into memory.
     
    First time writing a dll as well; however...
     
    Apparently windows defender thinks it's a Trojan ಠ_ಠ I didn't think my c++ was that bad, but ok
     
    Also one step closer to a h2v map parser. I think I'm going to keep going at it.
  11. tarikja liked a post in a topic by Zatarita in SeT team - progress   
    So, I finally did my first build of what I'm now calling the anniversary SDK or A-sdk for a pck unpacker. It works for everything except shared.pck. I need to write a light weight handler that doesn't load everything into memory.
     
    First time writing a dll as well; however...
     
    Apparently windows defender thinks it's a Trojan ಠ_ಠ I didn't think my c++ was that bad, but ok
     
    Also one step closer to a h2v map parser. I think I'm going to keep going at it.
  12. Tucker933 liked a post in a topic by Zatarita in MCC - compression formats (pc)   
    Halo MCC introduced compression to some of the game files. All of these formats are generally the same concept, but applied in different ways. In this topic, we're going to discuss the different forms of compression found in a few of the MCC halo versions. Primarily halo cea, and h2a pc. Compression on h1a standalone release for the 360 is different.
     
    Each of the compression algorithms use zlib compression. Generally the file gets broken up into certain size chunks, each chunk gets compressed and laid out sequentially. An offset to the beginning of each chunk is stored in the header along with chunk count. Each algorithm uses a variation of this technique, and I will cover the three main ones.
     
    H1A compression - Used in halo 1 anniversary files (*.map, *.s3dpak, *.ipak)
    H2A compression - Used with halo 2 anniversary non-map files (*.pck)
    H2Am compression - Used with halo 2 anniversary map files (*.map)
     
    H1A Compression
     
    H2A Compression
     
    H2Am Compression
  13. Tucker933 liked a post in a topic by Zatarita in SeT team - progress   
    Migration to c++ is chugging along. Compression is broken for now; however, I have parsing of s3dpaks and imeta down. (See: https://github.com/Zatarita/SeT-CPP) don’t judge my c++ lol
     Decided I want to see what changes the tags have In h2v -> h2a.
     Extracting tags seems to be a bit more difficult for h2 than I thought with existing tools (and I lost my original cd), so I’m just writing my own library for it. It’ll make things easier anyway having access to both engines, I’ll likely do the same for cea as well so I can link together the pieces from blam to saber 
  14. Tucker933 liked a post in a topic by Zatarita in MCC - compression formats (pc)   
    Halo MCC introduced compression to some of the game files. All of these formats are generally the same concept, but applied in different ways. In this topic, we're going to discuss the different forms of compression found in a few of the MCC halo versions. Primarily halo cea, and h2a pc. Compression on h1a standalone release for the 360 is different.
     
    Each of the compression algorithms use zlib compression. Generally the file gets broken up into certain size chunks, each chunk gets compressed and laid out sequentially. An offset to the beginning of each chunk is stored in the header along with chunk count. Each algorithm uses a variation of this technique, and I will cover the three main ones.
     
    H1A compression - Used in halo 1 anniversary files (*.map, *.s3dpak, *.ipak)
    H2A compression - Used with halo 2 anniversary non-map files (*.pck)
    H2Am compression - Used with halo 2 anniversary map files (*.map)
     
    H1A Compression
     
    H2A Compression
     
    H2Am Compression
  15. Tucker933 liked a post in a topic by Zatarita in MCC - compression formats (pc)   
    Halo MCC introduced compression to some of the game files. All of these formats are generally the same concept, but applied in different ways. In this topic, we're going to discuss the different forms of compression found in a few of the MCC halo versions. Primarily halo cea, and h2a pc. Compression on h1a standalone release for the 360 is different.
     
    Each of the compression algorithms use zlib compression. Generally the file gets broken up into certain size chunks, each chunk gets compressed and laid out sequentially. An offset to the beginning of each chunk is stored in the header along with chunk count. Each algorithm uses a variation of this technique, and I will cover the three main ones.
     
    H1A compression - Used in halo 1 anniversary files (*.map, *.s3dpak, *.ipak)
    H2A compression - Used with halo 2 anniversary non-map files (*.pck)
    H2Am compression - Used with halo 2 anniversary map files (*.map)
     
    H1A Compression
     
    H2A Compression
     
    H2Am Compression
  16. Tucker933 liked a post in a topic by Zatarita in MCC - compression formats (pc)   
    Halo MCC introduced compression to some of the game files. All of these formats are generally the same concept, but applied in different ways. In this topic, we're going to discuss the different forms of compression found in a few of the MCC halo versions. Primarily halo cea, and h2a pc. Compression on h1a standalone release for the 360 is different.
     
    Each of the compression algorithms use zlib compression. Generally the file gets broken up into certain size chunks, each chunk gets compressed and laid out sequentially. An offset to the beginning of each chunk is stored in the header along with chunk count. Each algorithm uses a variation of this technique, and I will cover the three main ones.
     
    H1A compression - Used in halo 1 anniversary files (*.map, *.s3dpak, *.ipak)
    H2A compression - Used with halo 2 anniversary non-map files (*.pck)
    H2Am compression - Used with halo 2 anniversary map files (*.map)
     
    H1A Compression
     
    H2A Compression
     
    H2Am Compression
  17. Tucker933 liked a post in a topic by Zatarita in MCC - compression formats (pc)   
    Halo MCC introduced compression to some of the game files. All of these formats are generally the same concept, but applied in different ways. In this topic, we're going to discuss the different forms of compression found in a few of the MCC halo versions. Primarily halo cea, and h2a pc. Compression on h1a standalone release for the 360 is different.
     
    Each of the compression algorithms use zlib compression. Generally the file gets broken up into certain size chunks, each chunk gets compressed and laid out sequentially. An offset to the beginning of each chunk is stored in the header along with chunk count. Each algorithm uses a variation of this technique, and I will cover the three main ones.
     
    H1A compression - Used in halo 1 anniversary files (*.map, *.s3dpak, *.ipak)
    H2A compression - Used with halo 2 anniversary non-map files (*.pck)
    H2Am compression - Used with halo 2 anniversary map files (*.map)
     
    H1A Compression
     
    H2A Compression
     
    H2Am Compression
  18. Tucker933 liked a post in a topic by Zatarita in SeT team - progress   
    okay! I finally have a bit more time to break down where we're at.

    CEA:
    Starting off SeT-cpp has been started, and initialized. My c++ is a bit rusty; however, hopefully it'll pay off in the long run.
    https://github.com/Zatarita/SeT-CPP
    Right now Imeta is only really implemented, and parsing scenedata. still needs a lot of work, and there are no fail safes currently. So it's more for reference's sake right now.

    CEA base file types:
    For the primary file types associated with CEA, we've pretty much managed to map out 99% of the structures and definitions for the base data types, and we've been moving into understanding the files in the files. The last few unknowns for the imeta was found to be depth, only leaving certain file types in s3dpaks as "uncertain"; however, luckily the names we have for them now will work until more information is found out.

    CEA sub-file types:
    This is where we've been spending a lot of our time, primarily on my front with templates.
    We've been making some progress. though, there's still a lot to go. We've determined the template system is a sentinel system. Each struct is defined as an 2 byte enumeration, and a 4 byte end of block offset. making it layout similarly to a binary tree layout/c structs. This sentinel block structure is used EVERYWHERE, so there are a lot of sentinels to figure out for almost every file inside of s3dpaks. for now, focusing on templates:
     
    To better understand what I mean, here is an example assault rifle template.




    In this example all the end of block (eob) are colored blue, and each sentinel block has its own color (kinda)
    First looking at yellow (0x02e4) this is the sentinel that denotes a template object. So this first sentinel lets the parser know to expect a template type, and it's 0x30cea till the end of block. Technically this entire file is the first block, and every other block is contained in this block. I like to visualize it as
     
    template {     //0x30cea bytes of SOMETHING } now let's expand on this.
    in purple we have the sentinel for filename (0x02e5), the end of block for filename (0x23), and the value of filename (LPTAassault_rifle.tpl).
    in orange we have an unknown sentinel type (0x0316), the end of block (0x2c), and the value of what 0x0316 holds. 3 bytes of something.
    in green we have a textures array (0x0156), the end of block(0xf6), and the value of what 0x156 holds. which in this case is a bit more interesting than the others.
    the textures array has a 4 byte count of how large the array is. Followed by more sentinel, end of block pairs. This is all contained within the textures array block. these sentinels are texture names, with end of block again. Going back to our original visualization we can kinda look at it like this:
     
    template { char* file_name = "LPTAassault_rifle.tpl"; // 0x02e5 unknown structure; // 0x0316 textures[count] = { "lig_ray_cone3", "sc_blue_0", "sfx_arifle_flame_01", "wpn_assault_display", "wpn_assault_display_3p_back_01", "wpn_assault_display_3p_digits_01", "wpn_assault_rifle_01"}; // 0x0155 ... //^ 0x0156 } this is what's been taking us so long to map out the templates and files. A lot of the structures are just one variable, and it's hard to guess what some of them do without some more pieces. It's like a giant sudoku puzzle.

    I will type out more in future posts, the snow is overloading my browser though, so I have to type in small bursts and refresh the page
  19. Tucker933 liked a post in a topic by Zatarita in SeT team - progress   
    okay! I finally have a bit more time to break down where we're at.

    CEA:
    Starting off SeT-cpp has been started, and initialized. My c++ is a bit rusty; however, hopefully it'll pay off in the long run.
    https://github.com/Zatarita/SeT-CPP
    Right now Imeta is only really implemented, and parsing scenedata. still needs a lot of work, and there are no fail safes currently. So it's more for reference's sake right now.

    CEA base file types:
    For the primary file types associated with CEA, we've pretty much managed to map out 99% of the structures and definitions for the base data types, and we've been moving into understanding the files in the files. The last few unknowns for the imeta was found to be depth, only leaving certain file types in s3dpaks as "uncertain"; however, luckily the names we have for them now will work until more information is found out.

    CEA sub-file types:
    This is where we've been spending a lot of our time, primarily on my front with templates.
    We've been making some progress. though, there's still a lot to go. We've determined the template system is a sentinel system. Each struct is defined as an 2 byte enumeration, and a 4 byte end of block offset. making it layout similarly to a binary tree layout/c structs. This sentinel block structure is used EVERYWHERE, so there are a lot of sentinels to figure out for almost every file inside of s3dpaks. for now, focusing on templates:
     
    To better understand what I mean, here is an example assault rifle template.




    In this example all the end of block (eob) are colored blue, and each sentinel block has its own color (kinda)
    First looking at yellow (0x02e4) this is the sentinel that denotes a template object. So this first sentinel lets the parser know to expect a template type, and it's 0x30cea till the end of block. Technically this entire file is the first block, and every other block is contained in this block. I like to visualize it as
     
    template {     //0x30cea bytes of SOMETHING } now let's expand on this.
    in purple we have the sentinel for filename (0x02e5), the end of block for filename (0x23), and the value of filename (LPTAassault_rifle.tpl).
    in orange we have an unknown sentinel type (0x0316), the end of block (0x2c), and the value of what 0x0316 holds. 3 bytes of something.
    in green we have a textures array (0x0156), the end of block(0xf6), and the value of what 0x156 holds. which in this case is a bit more interesting than the others.
    the textures array has a 4 byte count of how large the array is. Followed by more sentinel, end of block pairs. This is all contained within the textures array block. these sentinels are texture names, with end of block again. Going back to our original visualization we can kinda look at it like this:
     
    template { char* file_name = "LPTAassault_rifle.tpl"; // 0x02e5 unknown structure; // 0x0316 textures[count] = { "lig_ray_cone3", "sc_blue_0", "sfx_arifle_flame_01", "wpn_assault_display", "wpn_assault_display_3p_back_01", "wpn_assault_display_3p_digits_01", "wpn_assault_rifle_01"}; // 0x0155 ... //^ 0x0156 } this is what's been taking us so long to map out the templates and files. A lot of the structures are just one variable, and it's hard to guess what some of them do without some more pieces. It's like a giant sudoku puzzle.

    I will type out more in future posts, the snow is overloading my browser though, so I have to type in small bursts and refresh the page
  20. Tucker933 liked a post in a topic by Zatarita in SeT team - progress   
    Progress update!
    The team has been primarily focusing on h2a as of late. We've been able to map out most of the template format; however, there are still a bunch of unknowns. There is two major speed bumps we're stuck on; However, when I post the technical update it might give the community a chance to brainstorm with us, all help is appreciated! c:
    Besides this I've been migrating the SeT SDK to c++ to better utilize threading. It'll be built into a dll for anyone who wants to use it to create their own tools.
    The python modules will still be worked on as well.
     
    I will have a more technical update over the weekend for those interested
  21. Tucker933 liked a post in a topic by Zatarita in QuiCript - H1A/H2A context menu de/compressor   
    I made a "quality of life" script to help with handling compressing and decompressing h1a/h2a files. This adds a shortcut to compress/decompress in the windows context "send to" menu.



    Since H2A_inflate couldn't handle compression, this almost acts like a successor to it.
    I got tired of having to open up a cmd every time I wanted to compress with H2A inflate, or CEAflate.

    ***
    Note: this script requires python
    ***

    To install is simple. Download the .zip file. Then press windows key + r to open a run dialog. Type %appdata% in there, and it should open a file browser in your appdata's roaming folder. Extract QuiCript into that folder. Voila, it should show up inside your send to menu. I originally wanted to give it it's own action; however, that requires editing the registry, and I personally find that a bit extreme for something like this.
     


     
     
    This script WILL replace the original file; however, it's designed to only do so if it successfully decompresses the file, you can always "undo" by recompressing. Err on the side of caution, and always keep backups.
    QuiCript.zip
  22. Zatarita liked a post in a topic by aLTis in Halo: Minecraft Edition   
    This is a campaign mod that adds some of Minecraft's features to Halo CE. You have 3 weapons and various blocks that you can use to build things. You can also choose from 16 player skins. Read the readme file for more info.
     
    Download:
    https://mega.nz/file/MTRUiZzY#SJ4EyIEo2l_yeHPFgflgNzC9PPAXMngnnoP_OsZHKKI
    http://www.mediafire.com/file/bg8gfjnx53ido90/HaloMinecraftMod1,1.rar/file
     
    Credits:
    aLTis - scripting and tag work Benji-Mod - some of the original tags (bow and sword) Kinnet - UI Vuthakral - help with the character model Refined Halo Development Team - some tag fixes Textures and sounds have been ripped from Minecraft Skins: reekid487, SkullBelly, ShaungJi123, Hellcraftjz, ElectroDr0p, Tin711, skad03, LordProtoTypeV3, Shempimite, Seileach, AliveR360, Johnny Joestar Testers: Kinnet, Reus, The Lobo, ShaungJi123, and others  
     
    BTW here's the lua script that's used in every map, someone may find this stuff useful idk a10.lua
  23. Tucker933 liked a post in a topic by Zatarita in QuiCript - H1A/H2A context menu de/compressor   
    I made a "quality of life" script to help with handling compressing and decompressing h1a/h2a files. This adds a shortcut to compress/decompress in the windows context "send to" menu.



    Since H2A_inflate couldn't handle compression, this almost acts like a successor to it.
    I got tired of having to open up a cmd every time I wanted to compress with H2A inflate, or CEAflate.

    ***
    Note: this script requires python
    ***

    To install is simple. Download the .zip file. Then press windows key + r to open a run dialog. Type %appdata% in there, and it should open a file browser in your appdata's roaming folder. Extract QuiCript into that folder. Voila, it should show up inside your send to menu. I originally wanted to give it it's own action; however, that requires editing the registry, and I personally find that a bit extreme for something like this.
     


     
     
    This script WILL replace the original file; however, it's designed to only do so if it successfully decompresses the file, you can always "undo" by recompressing. Err on the side of caution, and always keep backups.
    QuiCript.zip
  24. Tucker933 liked a post in a topic by Zatarita in QuiCript - H1A/H2A context menu de/compressor   
    I made a "quality of life" script to help with handling compressing and decompressing h1a/h2a files. This adds a shortcut to compress/decompress in the windows context "send to" menu.



    Since H2A_inflate couldn't handle compression, this almost acts like a successor to it.
    I got tired of having to open up a cmd every time I wanted to compress with H2A inflate, or CEAflate.

    ***
    Note: this script requires python
    ***

    To install is simple. Download the .zip file. Then press windows key + r to open a run dialog. Type %appdata% in there, and it should open a file browser in your appdata's roaming folder. Extract QuiCript into that folder. Voila, it should show up inside your send to menu. I originally wanted to give it it's own action; however, that requires editing the registry, and I personally find that a bit extreme for something like this.
     


     
     
    This script WILL replace the original file; however, it's designed to only do so if it successfully decompresses the file, you can always "undo" by recompressing. Err on the side of caution, and always keep backups.
    QuiCript.zip
  25. Tucker933 liked a post in a topic by Zatarita in QuiCript - H1A/H2A context menu de/compressor   
    I made a "quality of life" script to help with handling compressing and decompressing h1a/h2a files. This adds a shortcut to compress/decompress in the windows context "send to" menu.



    Since H2A_inflate couldn't handle compression, this almost acts like a successor to it.
    I got tired of having to open up a cmd every time I wanted to compress with H2A inflate, or CEAflate.

    ***
    Note: this script requires python
    ***

    To install is simple. Download the .zip file. Then press windows key + r to open a run dialog. Type %appdata% in there, and it should open a file browser in your appdata's roaming folder. Extract QuiCript into that folder. Voila, it should show up inside your send to menu. I originally wanted to give it it's own action; however, that requires editing the registry, and I personally find that a bit extreme for something like this.
     


     
     
    This script WILL replace the original file; however, it's designed to only do so if it successfully decompresses the file, you can always "undo" by recompressing. Err on the side of caution, and always keep backups.
    QuiCript.zip