Alef/modmixer – User
mNo edit summary |
mNo edit summary |
||
Line 1: | Line 1: | ||
==Idea== | ==Idea== | ||
A program | 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 | 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, | 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. | ||
A player wants to try that "mix". He downloads the recipe and the key. | |||
Then, download the mods, | Then, download the "ingredients" mods, as required by the recipe. | ||
With | With modmixer, he produces the same pbo the cook created at his time. | ||
The pbo, together with the | 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 | 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 21: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