Alef/modmixer – User

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
m (Text replacement - " (={2,})([^ = ])(.*)([^ = ])(={2,}) * " to " $1 $2$3$4 $5 ")
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
==Idea==
WIP (nearly RIP)
A program which take in input downloads mods (.zip, .7z, .rar, .pbo) and produce a single .pbo given a command file.
== Idea ==
A program that take as input downloaded mods (.zip, .7z, .rar, .pbo) and produce more .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 files signed, and both put online (the recipie + the .bisignS).


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.
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.


==Workflow==
All of this should skip the need to obtain permissions from mod authors for incorporate their works.
The "cook" will mix some mods through the application, and produce a recipe.
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.
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 files, 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 files the cook created at his time.
The pbo, together with the keys, 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 public key, the pbo above will be trusted too.
In MP, if the server has the cook's public key, the PBO files 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?).
**content:
*** human readable list of mods for input, with optional URLs. No unattended downloads.
*** for each target pbo
**** list of sources pbo
**** list of dup config values to copy in
**** bspath to apply on resources
**** ...
* 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

Latest revision as of 20:15, 31 January 2021

WIP (nearly RIP)

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?).
    • content:
      • human readable list of mods for input, with optional URLs. No unattended downloads.
      • for each target pbo
        • list of sources pbo
        • list of dup config values to copy in
        • bspath to apply on resources
        • ...
  • 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