RBPatch v1.4.3 - Copyright (c) 2002 Joel Bierling and Miro Torrielli

1. Release Notes

Red Baron Patch Manager (RBPatch) is a patch management application for Red Baron II/3D. All Campaign Manager (CM11) patch management features have been fully implemented and hopefully improved upon. RBPatch’s patch format is fully CM11 compatible. This should be the last 1.x version, unless serious flaws are discovered.

Please report any bugs to mtorrielli@mag-cor.com and leave your comments at benchmarksims.com.

2. Using RBPatch

If upgrading from CM11, simply move all subfolders of CM11\Patches into RBPatch\. If not, please note that most recent patches such as WFP, OTE 4-Seasons, etc., will work out of the box by unzipping them into RBPatch\. For patches that are not distributed in CM11 format, such as Revenge of the Jastas, you must create a folder for the patch in RBPatch\, and then unzip the patch into a subfolder of this newly created folder, corresponding to the directory in Data where these files should go. In the above example (ROTJ), unzip the ROTJ archives into RBPatch\ROTJ\SimPatch or RBPatch\ROTJ\ShellPat.

You must now run RBPatch.exe. Hit the "Browse" button next to the "Launch" button and select Baron.exe in your Red Baron II/3D directory.

There will be no patches present yet, so you must select "Tools->Add Patch" from within the RBPatch application. Fill in the blanks, and make sure that "Patch Folder" corresponds to an existing patch directory located within the RBPatch folder. Please note, you must ensure that no patches are currently applied before adding a new one.

Once the patch has been created, you must reload RBPatch by selecting "View->Reload". You will now see your newly created patch in the main RBPatch window. The empty square box indicates that the patch has not yet been applied.

To apply the patch, simply click on the square box to check it, then click on the "Apply Changes" button.

If the patch is date-based, such as WFP, you must apply a date. Select "Tools->Set Date". You have three options:

1) Enter a date manually (yymmdd) by filling in the date and hitting "Ok".

2) Set the date by grabbing it from a saved campaign. Hit "Browse" to select one of your campaign files.

3)  Modify one of your campaign files. Enter a date manually, then hit the "Modify Campaign" button to select one of your saved campaigns.

All three will update your SimPatch directory with all appropriate date files from your date-based patches. The difference lies in the fact that in the third case, you are moving your campaign to the specified date, which obviously gives you access to earlier dates than Red Baron allows in the Pilot Setup menu.

Please keep in mind that you must always set a date right after adding a date-based patch before playing Red Baron II/3D.

Furthermore, RBPatch will not allow you to overwrite the files of one patch with files from another patch, unless the latter is a sub-patch of the former. This is a feature, by the way. You must therefore make sure that there are no conflicting files in your patches. Unlike CM11, RBPatch will simply not allow you to apply a patch that conflicts with another currently applied patch.

For patches such as OTE 4-Seasons that contain mini-patches (spring, summer, autumn, winter), and WFP (WFPFM, DMv1.1, MvR, DeltaK, etc.), you must set these so-called "mini-patches" as children of the main patch, or they will not apply. Use the "Tools->Add Sub-Patch" Dialog to add such "mini-patches".

3. RBP File Format

If you want to create patches for RBPatch, take a look at a .rbp file in a text editor. The format should be fairly obvious. To make a line a comment, put a semicolon as the first character on the line.

Every .rbp patch has a unique identifier. This is called a GUID (Globally Unique IDentifier). GUID's are very important for several reasons. The first thing they do is give RBPatch a reliable way of identifying a specific patch.

This appears in the .rbp as:
[ID]
ID=518E65C5-9438-11B2-85AB-0050046B61BF

.rbp files can also specify their parent patch. This can be specified in two different ways. First a patch can directly reference a parent by including "ParentID=518E65C5-9438-11B2-85AB-0050046B61BF" in the [ID] section, or the parent .rbp file can define a subdirectory to look for .rbp files in with the path group option. This looks like:

[Options]
CheckGroup/OptionGroup
PathGroup=Labels

All the .rbp files in the PathGroup subdirectory will automatically become child files of the .rbp that specified the PathGroup.

Look at the Labels.rbp patch for an example of this.

So now you've defined parent and child relationships. These are reflected in the RBPatch UI in the tree structure. For patches that replace entire files, having a copy of a new file of the parent and the original file of its child would be inefficient since they would be exactly the same file. For this reason you can include the special key "<ParentNew>" instead of a file name for the original copy of a file.

To help create [PatchInfo] sections, you can use the Tools->Create PatchInfo file... menu option. When you use this you will first have to pick the original file, then you will have to pick the new file, and then you will have to pick the file you would like the diff information to be saved to. The diff file that is created will have everything you need to create a [PatchInfo] section. The file name that the diff file uses will have a full path. You will want to cut this down to its relative path in order to use it.

The [FileInfo] and [ZipInfo] sections have a special ability. First of all these sections normally work with original and new files that come with RBPatch. For some uses, such as replacing sounds or movies, including the original copy of a file with RBPatch would be prohibitive because of the large size. To get around this limitation start the original file name with "Persist\". RBPatch will recognize this special phrase and make a backup of the original file into to the "RBPatch\Persist\" directory when the patch is applied. Then when the patch is unapplied, RBPatch will copy the original file out of the Persist directory back into its correct location.

An .rbp file is made up of several different sections. Unneeded sections can be omitted. The format of an .rbp is:

[ID] - Identifies this patch and any relationships.
ID=GUID - Unique identifier for this patch.
ParentID=GUID - Identifies this patches parent.
RefreshID=GUID - A list of patches to refresh when this patch is applied or unapplied.
OnAddApplyID - Apply another patch when this .rbp is applied.
OnAddUnapplyID - Uanpply another patch when this .rbp is applied.
OnRemoveApplyID - Apply another patch when this .rbp is unapplied.
OnRemoveUnapplyID - Unapply another patch when this .rbp is unapplied.

[Name] - The name you want to display.

[Description] - The description you want to display.

[Creator] - Who created the patch or enhancement.

[Credit] - Does anyone else deserve credit?

[Readme] - File with more information about the patch.

[Options]

1. SkipVerify - RBPatch skip verification checks to make sure that it can back out the patch.
2. <!SkipTest!> - This flag is not really part of the [Options] section but is used on individual lines for specifying to RBPatch that it should skip the verification and patch application status of a specific instruction.
3. OptionGroup - Indicates that this .rbp file is a parent that has mutually exclusive children.
4. CheckGroup - Indicates that this .rbp file is a parent that has child patches.
5. PathGroup={Folder Path} - Indicates that RBPatch should check the specified folder for additional .rbp files. The .rbp files found will be displayed as children of this group.
6. AutoAdd - Indicates that RBPatch should set this child checkbox patch to apply when its parent is applied.
7. RBPFolder - Tells RBPatch to search the folder specified with the PathGroup option for more patches. The patches that are found will not appear as child patches of this .rbp.
8. Refresh - Tells RBPatch to recheck the applied status of this patch whenever it is applied or unapplied. This is used for patches that reset default values.
9. PackageOptional - Tells RBPatch that this patch should not be automatically applied when it is part of a package.
10. NoPackage - Tells RBPatch to keep this patch from being added to packages (keeps private patches private).
11. ToolCommand - This .rbp will now appear in the tool menu and operate as a menu command.

[AddAlert] - A message that is displayed when a patch is set to be applied.

[RemoveAlert] - A message that is displayed when a patch is set to be unapplied.

[Registry] - Registry entries
ROOT\Key\Value \\ {Action [<ReplaceSubString>]} \\ Orig Value \\ New Value

[DirectoryInfo] - Directory operations
{Action [<Create>]} : {Directory Name}

[FileInfo] - Complete files you want to replace
{FilePath from defined exe} - {Orig Replacement File}, {New Replacement File}
See the Persist section for more information.

[PatchInfo] - Patch list for the user defined exe.
{Offset} - {Orig Hex}, {New Hex}

[FileName] - Name of zip file.
{FilePath from defined exe}

[ZipInfo] - Files within the FileName zip file that you want to replace.
{FilePath from defined exe} - {Orig Replacement File}, {New Replacement File}
See the Persist section for more information.

[FileName] - >Name of another file you want to patch.
{FilePath from defined exe}

[PatchInfo] - Patch list for the .rbp defined file.
{Offset} - {Orig Hex}, {New Hex}

[FileName] - >Name of another file you want to patch.
{FilePath from defined exe}

[TextInfo] - Text change list for the .rbp defined file.
{Action [<ReplaceSubString>]},{Delimiter},Orig Text{Delimiter}New Text

[PluginInfo] - Plugin list
{Plugin filename}:{Plugin defined data}

[ShellInfo] - Execute other programs
{Type [Apply | Unapply]} = {Path [<SystemCommand> | <RBPatchDir> | <InstallDir>] : Command
doesn't add any path on to the command
adds the path of the RBPatch directory to the beginning of the command.
is the RedBaronII directory.

[ShortcutInfo] - Install shortcuts
{FilePath from defined exe}

4. Installation Packages

Once you've written your .rbp files you probably want to distribute them to other people. You have two choices. If the people you are distributing your work to already have RBPatch you can simply send them your .rbp files. If they don't have RBPatch you may want to create an Installation Package for them.

To create an installation package, use the Tools->Create Installation Package menu command. This will present you with a dialog giving you some options for your installation package. Once you have selected the options you like, you will be asked to provide the name of your installation package. Once you provide this, RBPatch will create a special executable that will contain all the patches you have selected in one executable that can be easily given to others and used by them.

The package options are:

12. Patch Selection

1. Selected Patches - Only include the patches that are currently selected (have a checkmark or circle with a dot in it next to the name) in the package.
2. All Patches - Include all the patches regardless of whether they are selected.
3. Highlighted Patch - Only the patch that is currently highlighted (the name is surrounded by blue).
12. Interface
1. Simple - Dislays a small screen that only has a few buttons on it. This option is recommended when distributing packages to people that aren't familiar with RBPatch.
• Hide Advanced Interface - Normally the Simple interface has a button that will allow the user to switch to the Advanced interface. Selecting this option will remove this button from the screen.
2. Advanced - The normal RBPatch screen that gives you the power to patch as you please.
13. Include Exe - Includes the currently selected exe (the one displayed in the box next to the "Executable:" label on the main screen into the package. It is highly recommended that if you include an exe that you give it a unique name. For example "RedBaronII_MyExe.exe". That way if people uninstall your patch, they'll still have an executable.
1. Install Icon on Desktop - If the package installs an exe, this option will create a shortcut to that exe on the user's desktop.
2. Keep Exe on Unapply - Normally when the package is unapplied, RBPatch will also delete the exe that was installed. Checking this option will keep the exe in place.
14. Allow Expand Package - Normally users have the option of expanding the packages so they can add to the list of patches that they are using. Checking this option will remove this ability.
15. Include All Plugins - Normally RBPatch will only include plugins that are used by patches that are going into the package and plugins that appear on the Tools menu. This option will include all loaded plugins regardless of whether they are used.

Note: If you include an exe named Baron.exe then when people apply your patch, it will overwrite their existing Baron.exe. Then if people unapply your patch, RBPatch will delete RedBaronII.exe leaving them without an exe. If your included exe is named something unique then this problem is averted.

>>EOF<<