Alef/modmixer – User

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 1: Line 1:
==Idea==
==Idea==
A program which take in input downloads 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 a single .pbo given a command file.


This 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). Other 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 "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.
The key will validate the pbo, because we suppose the input file are the very same and the output too.


All of this should skip the requirement to obtain permissions from mod authors to incorporate their work in another one. People will download their mods as usual, if needed, the website will have their adv shown, and everyone is happy.
All of this should skip the need to obtain permissions from mod authors for incorporate their work in another one.
People will download their mods as usual, the websites will have their adv shown.


==Workflow==
==Workflow==
The "cook" will mix some mods through the application, and produce 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 key is created.
With the resulting .pbo, and the author private key, a .bisign key is created.
The recipe and the key are put online.
The recipe and the key are then put online.


The player want 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 mods, if he doesn't already have them.
Then, download the "ingredients" mods, as required by the recipe.
With the mixer, produce the same pbo the cook created at his time.
With modmixer, he produces the same pbo the cook created at his time.
The pbo, together with the keys, goes in some @modfolder/AddOns.
The pbo, together with the downloaded recipe key, goes in some @modfolder/AddOns.


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


==Assumptions==
==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.
* 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
** pbo
**** read pbo from zipped files
**** write the final pbo
*** config.bin
**** unrap config.bin files from pbo from zipped files
*** boost::wave
**** preprocess config.cpp
**** need special filesystem for buffered archives/pbo
**** may need access to real ArmA\ directory (registry key)
* config.cpp
** preprocessor
** parser
** write a new one base on the recipe

Revision as of 22:25, 12 January 2009

Idea

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

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. The key will validate the pbo, 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. People will download their mods as usual, the websites will have their adv shown.

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, 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 the cook created at his time. The pbo, 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.

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
    • pbo
        • read pbo from zipped files
        • write the final pbo
      • config.bin
        • unrap config.bin files from pbo from zipped files
      • boost::wave
        • preprocess config.cpp
        • need special filesystem for buffered archives/pbo
        • may need access to real ArmA\ directory (registry key)
  • config.cpp
    • preprocessor
    • parser
    • write a new one base on the recipe