Would be nice to have a binarize option for *.cpp and texture files to the packer.

Issue

When using W11, right clicking on a drive or folder in the navigation pane of File Explorer, and attempting to do any context menu action will crash File Explorer, and restart it.

Steps to re-produce

1. Open File Explorer
2. Right click any item in the left hand navigation pane
3. Hit "Properties" or any other context menu action
4. File Explorer restarts

Installer version of V1.4.0, yet to test on binaries version.

Currently, if the PBO already exists, the packing fails. It would be nicer to have a dialog asking if the user wants to overwrite the PBO.

As the title touches on, it would be nice if the program renamed the previous pbos in the directory instead of just failing to build with an error that it already exists. I understand why that's done, but it would make life easier if I didn't have to erase them to proceed each time.

At the moment, while a PBO file is saving, the main program UI is left clickable. That might cause unpredictable behavior if the user does changes in the file tree during the save operation.

The program UI must block when a save operation is in progress.

When loading a file UI hangs. If a file is small, it is hard to notice. But when a file is huge - it is noticeable.

Files have to be loaded in a background thread.

It is nice to have the Windows taskbar displaying the progress of what's the app doing in the background. And flash when the operation is complete.

If PBO contains two files: file1.sqf and file2.sqf, the user can not rename file2.sqf to file1.sqf, but can - into FILE1.sqf.

That is not correct. The user must not be able to rename file2.sqf to file1.sqf regardless of the case.

I've been working with https://github.com/Vdauphin/HeartsAndMinds/ recently and it uses a empty .sqf file that it will not work without (believe it gets compiled when the mission is being loaded) .

pboman3 1.6.0 keeps removing this file. We need a setting to disable any junk filter or what ever is removing it. As a workaround I have to keep adding the empty SQF (core/init_common.sqf) manually every time I make any changes.

The most frustrating thing about it is that is not communicated that it gets done, and it is done even when just opening a pbo, replacing one file and saving.

Run the command:

pbom.exe pack C:\MyMission -o C:\OutputFolder\

The expected result is: there is a file C:\OutputFolder\MyMission.pbo

The actual result is: there is the file C:\OutputFolder.pbo

Hey there, I am not able to open some PBOs. These are missions and addons, all of them working fine in Arma and I am able to open them with other PBO tools like the old PBO manager.

Where would I send the PBOs for you to test and hopefully come up with a fix if possible?

There should not be .pbo here:

When the program tries to open a mangled PBO with the latest version of Mikero (DePbo.dll.9.11), the program crashes and then a .dmp appears in the system CrashDumps folder.

If you need any PBO to test it, do not hesitate to contact me.

The .msix build available in releases for version 1.6.0 won't let me install, for the following reason:

This app package’s publisher certificate could not be verified. Contact your system administrator or the app developer to obtain a new app package with verified certificates. The root certificate and all immediate certificates of the signature in the app package must be verified (0x800B010A)

When I unpack mission or addon, it shows me this promt, that it is done and I need to click on button "Close" or click "X" to close it.
Please remove this prompt in completion.

Show it only, if there is a problem with unpacking.
Make a setting in software to disable/enable prompt on completion.

https://images2.imgbox.com/84/ab/110zsfVD_o.png

I just had to unpack and repack 157 PBO files which the old PBO Manager 1.4b was unable to do in bulk. I have used that program for so long that I instinctively associate the red archive folder with PBO files. I would like the option to change the file icon so I can still use the instantly recognizable one I have used for so long.

In Settings, the 3rd tick box option for "In the case of file conflict when packing a PBO:" has a typo in it, "Owerwrite the existing file", should be "Overwrite".

Hey there, seeing as you can open "mangled" pbos by Mikero's tools, I think it would be cool to add at least somewhat automated deobfuscation.

From my understanding, it only changes the config.cpp etc to use #include "weirdAssName" to inlcude those random characters.
For example a config.cpp containing #include "ўЯњљЦ*�уаџѐ", renamiming "ўЯњљЦ*�уаџѐ" to "config.cpp" actually shows the correct config.cpp.

This feature would be really appreciated.

Would be fun to have an option to prevent UI from opening when we use command line.
Thanks

I'm trying to unpack an Antistasi pbo and then repacking loses 4mb of data and causes the mission to no longer start I can provide any files

1. Have a pbo with a text file file1.txt.
2. Open the file1.txt notice its contents.
3. Replace the file1.txt with another file with another content.
4. Open the file1.txt. Notice the file1.txt content is from the original file. While the expected result is the file1.txt having the new content.

File extraction does not work properly on Ver 1.5.0.
pbo.json is generated when perform extraction.
Installation destination is local. (Just for me)

Ver 1.4.1 can be extraction correctly.
also extract it with Mikero's ExtractPbo is without any problems.

Maybe the latest Windows 10 update is the culprit. I recently did a clean install of Windows 10.
Edition/Version: Windows 10 Home 22H2 built 19045.2913

pbo.json contents is below.
{ "compress": { "exclude": [ ], "include": [ ] }, "headers": [ { "name": "prefix", "value": "myaddonname" } ] }

I have several mod and mission PBOs that now look as if they have no content at all, but they contain just plain ASCII filenames and were created using Arma tools. I am not sure what specific issues PBO sees with them. Also, at least one mod that can be easily unpacked with unpbo (Mikero) that has a plain config.cpp will have that file be binary junk when unpacked with PBO Manager (though I am not sure this is the same issue). All of this works just fine with 1.4.1.

There is an spelling error under View, see picture below.

Any plans on adding support for the new Windows 11 context menu?

Right now PBOMan3 will throw out error if user tries to pack a folder into a PBO which name is already used in the same directory, so it has to be manually removed, the manager window closed and whole packing action repeated. Old PBO Manager could just overwrite the existing PBO and copy the older version as .pbo.old. This was very useful and would love to see the same here.

Found a PBO (that most probably includes some kind of DRM and is obfuscated) that I'd love to take a peek into.

Had high hopes for PBOMan3, as it manages to open other obfuscated PBOs, but sadly does not manage with this one.

It starts to open it, CPU util ramps up, RAM usage is slowly increasing. The PBO itself is around 350BM. RAM usage went to about 250BM, which took about half an hour. After that, it got reset and started to slowly climb again.

How could I provide you with the PBO for testing? It's not meant to be shared publicly.

I'm trying to edit a mission but when it's time to repack it, pbo manager halves the size of the pbo. Using your old pbo manager doesn't seem to cause any problems..

.