Alef/modmixer – User

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
m (more PBOS for name clashing)
Line 1: Line 1:
==Idea==
==Idea==
A program that take as input downloaded mods (.zip, .7z, .rar, .pbo) and produce a single .pbo given a command file.
A program that take as input downloaded mods (.zip, .7z, .rar, .pbo) and produce more .pbo given a command file.
 
The "command file" is the "recipe" for the mix. A ''recipe'' would be created by someone, the resulting PBO files signed, and both put online (the recipie + the .bisignS).


The "command file" is the "recipe" for the mix. A ''recipe'' would be created by someone, the resulting pbo signed, and both put online (the recipie + the sign).
Players can download them and produce their own mix, based on the recipe.
Players can download them and produce their own mix, based on the recipe.
The key will validate the pbo, because we suppose the input file are the very same and the output too.
The key will validate the PBO files, because we suppose the input file are the very same and the output too.


All of this should skip the need to obtain permissions from mod authors for incorporate their work in another one.
All of this should skip the need to obtain permissions from mod authors for incorporate their works.
People will download their mods as usual, the websites will have their adv shown.
People will download their mods as usual, the websites will have their ads shown, their download counts.


==Workflow==
==Workflow==
The "cook" will mix some mods through the application, producing a recipe.
The "cook" will mix some mods through the application, producing a recipe.
The recipe is a text file with zip/pbo/config references, in order.
The recipe is a text file with zip/pbo/config references, in order.
With the resulting .pbo, and the author private key, a .bisign key is created.
With the resulting PBO files, and the author private key, a .bisign key is created.
The recipe and the key are then put online.
The recipe and the key are then put online.


A player wants to try that "mix". He downloads the recipe and the key.
A player wants to try that "mix". He downloads the recipe and the key.
Then, download the "ingredients" mods, as required by the recipe.
Then, download the "ingredients" mods, as required by the recipe.
With modmixer, he produces the same pbo the cook created at his time.
With modmixer, he produces the same PBO files the cook created at his time.
The pbo, together with the downloaded recipe key, goes in some @modfolder/AddOns.
These, together with the downloaded recipe key, goes in some @modfolder/AddOns.


In MP, if the server has the cook's public key, the pbo above will be trusted.
In MP, if the server has the cook's public key, the PBO files above will be trusted.


==Assumptions==
==Assumptions==
Line 30: Line 31:
* I/O
* I/O
** don't uncompress stuff in temp directories, try to do everything in memory/buffer
** don't uncompress stuff in temp directories, try to do everything in memory/buffer
*** use 7z.dll
** pbo
** pbo
**** read pbo from zipped files
**** read needed pbo from zipped files
**** write the final pbo
**** write the final PBOs
***** PBOs need to be ordereed as the recipe says. Respect their $PREFIX$.
*** config.bin
*** config.bin
**** unrap config.bin files from pbo from zipped files
**** unrap config.bin files from pbo from zipped files
*** boost::wave
*** boost::wave
**** preprocess config.cpp
**** preprocess config.cpp
**** need special filesystem for buffered archives/pbo
**** need special filesystem for buffered archives/pbo entries
**** may need access to real ArmA\ directory (registry key)
**** may need access to real ArmA\ directory (found by BI regkey) ?
* config.cpp
* config.cpp
** preprocessor
** preprocessor
** parser
** parser
** write a new one base on the recipe
** write new configs based on the recipe

Revision as of 16:13, 13 January 2009

Idea

A program that take as input downloaded mods (.zip, .7z, .rar, .pbo) and produce more .pbo given a command file.

The "command file" is the "recipe" for the mix. A recipe would be created by someone, the resulting PBO files signed, and both put online (the recipie + the .bisignS).

Players can download them and produce their own mix, based on the recipe. The key will validate the PBO files, because we suppose the input file are the very same and the output too.

All of this should skip the need to obtain permissions from mod authors for incorporate their works. People will download their mods as usual, the websites will have their ads shown, their download counts.

Workflow

The "cook" will mix some mods through the application, producing a recipe. The recipe is a text file with zip/pbo/config references, in order. With the resulting PBO files, and the author private key, a .bisign key is created. The recipe and the key are then put online.

A player wants to try that "mix". He downloads the recipe and the key. Then, download the "ingredients" mods, as required by the recipe. With modmixer, he produces the same PBO files the cook created at his time. These, together with the downloaded recipe key, goes in some @modfolder/AddOns.

In MP, if the server has the cook's public key, the PBO files above will be trusted.

Assumptions

  • PBOs do not contain time-dependant information, that is, no timestamps or info like that. This is needed to produce the very same pbo as the cook, byte by byte.

Analysis

  • Recipe
    • a text file. Doesn't need to be human readable. Can be quite long. Optionally zipped (libz in boost_ios?).
  • I/O
    • don't uncompress stuff in temp directories, try to do everything in memory/buffer
      • use 7z.dll
    • pbo
        • read needed pbo from zipped files
        • write the final PBOs
          • PBOs need to be ordereed as the recipe says. Respect their $PREFIX$.
      • config.bin
        • unrap config.bin files from pbo from zipped files
      • boost::wave
        • preprocess config.cpp
        • need special filesystem for buffered archives/pbo entries
        • may need access to real ArmA\ directory (found by BI regkey) ?
  • config.cpp
    • preprocessor
    • parser
    • write new configs based on the recipe