Config editing and .bin problems

[gatordev 219]

In an effort to try and learn a bit more about configs, I've started digging into some weapon addons and their configs and then tweak them. I'm running into some issues that I'm sure are user-related, but hoping someone can help. DISCLAIMER: I'm messing with people's .pbo files for personal use and my own education. I have no intention of stealing or re-releasing anything.

I know many recommend using Eliteness, but I can't get it to work for me. I get an error that says the "side by side configuration is incorrect." the Depbo.dll is either in the same directory as Eliteness or in the systemwow64 folder. Same result, either way. So, with that out of the way, I've been using:

-PBOView to extract

-Unrap.exe to get to a readable .cpp

-BinTools to re-bin the config files.

So here's what happens...

-I Unrap the config .pbo of an addon. Let's call it "weapon_cfg.pbo" (basically I've been looking at RH's weapons). On two of the .pbo files, when I re-bin them, they work in-game, but now add an addon dependency for the _cfg .pbo.

-2 other .pbo files, when re-bin'ed don't ever show up in-game.

-When I extract and Unrap these two .pbo files, then don't do ANYTHING to the config.bin files and just re-PBO, I have the same problem...they don't show up in-game.

-When using Unrap, it does add some lines to the config.cpp. But when I don't even use Unrap, I get the same problem, it leaves me confused.

I'm sure I'm doing something wrong, but looking for some help. My simple education lesson turned into something more complicated, apparently. Appreciate any help.

[[aps]gnat 28]

Unfortunately you're doing non-standard editing and using the tools not really as intentioned, so theres a high chance things are going wrong.

From your description its still hard to understand what exactly you are doing, and to some degree, why.

If you Unrap an bin and edit the cpp, you dont have to turn it into a .BIN again. Once inside a PBO, it will work.

Are you saving virtually the same config/bin in one PBO, while leaving the original config/bin in another PBO? ......... in that case it will never work properly.

[mr burns 133]

-2 other .pbo files, when re-bin'ed don't ever show up in-game.

-When I extract and Unrap these two .pbo files, then don't do ANYTHING to the config.bin files and just re-PBO, I have the same problem...they don't show up in-game.

-When using Unrap, it does add some lines to the config.cpp. But when I don't even use Unrap, I get the same problem, it leaves me confused.

That pbo folder hasn´t got a *pboprefix* file sitting in it´s root by any chance?

If so, delete it and then repack.

I'm sure I'm doing something wrong, but looking for some help. My simple education lesson turned into something more complicated, apparently. Appreciate any help.

As Gnat said, it´s not the most common or recommended approach you are doing it.

In ArmA editing there´s mostly one way to do it right, but a gazillion to make it wrong - up until you´ve found most of the ways it doesn´t work, you´re screwed :o

[mikero 79]

>I get an error that says the "side by side configuration is incorrect."

you need a copy of vcredist_x86.exe

https://dev-heaven.net/projects/mikero-pbodll/files

this is in the dll readme and occurs for some people's systems where this file isn't present.

>same directory as Eliteness or in the systemwow64 folder

as the readme says. put it in system32, or same directory.

>DISCLAIMER: I'm messing with people's .pbo files

there is nothing dishonorable in that. breaking open pbo's to see what the hell's in there, let alone learning from what IS in there, is a time honored practice.

A pbo is a convenient distribution method. It's intention is identical to zip or rar. it's simply packaged content. If you weren't meant to break them open, they'd be encrypted.

-PBOView to extract

-Unrap.exe to get to a readable .cpp

-BinTools to re-bin the config files.

and blah blah. Eliteness covers all those bases. But, i encourage you to work with all these different tools that do the same thing so you get a handle on their strengths and weaknesses and, in the process come to understand the buzzwords each one uses to do basically, the same stuff.

The crippling factor for the above non-bis tools (and other tools of their kind) is that when the formats change, and trust me, they change, often. You just hope a new version will come along soon. Using the dll approach, the exe almost never changes, while the dll always reflects the latest engine improvements. backward compatible to the very first CWC demo

Enjoy

[[frl]myke 14]

If you weren't meant to break them open, they'd be encrypted.

PBO's can be encrypted? I mean by users, not only BIS? Care to share this knowledge?

[[aps]gnat 28]

NO! The community don't need to know this knowledge.

I'd rather not see us spirally down some toilet as everyone gets into in-fighting about protected content, who's material is REALLY inside, who's isn't and so on ... forever never to be the same as the LAST DECADE of acceptable methods.

If a maker truely feels they need to encrypt their PBO, they either a) have a commercial arrangment with BIS b) accidently joined the wrong community and didn't understand currently accepted norms.

Edited March 3, 2012 by [APS]Gnat

[.kju 3245]

Only BI can. People can only try to make it non readable by the community tools.

However this only works till the next tool patch fixes that.

[Synide 0]

Myke;2114568']PBO's can be encrypted? I mean by users' date=' not only BIS? Care to share this knowledge?[/quote']

There's not really any knowledge to share. As there's no .pbo encryption used in the A2/OA product range.

Mikero was simply saying if BIS really, really didn't want anyone to open (& learn) from .pbo's then they'd encrypt them. Like they do with their Mil product. If you're making stuff for that environment then you can produce encrypted content but that has nothing todo with ArmA2 & Operation Arrowhead. And, if you're thinking 'will that stuff' made for the mil product run under A2/OA? The answer is... no.

[gatordev 219]

Huh, for some reason, even though I subscribed to this thread with notifications, it never told me anyone replied. My apologies for coming back late.

Gnat;2114401']Unfortunately you're doing non-standard editing and using the tools not really as intentioned' date=' so theres a high chance things are going wrong.

From your description its still hard to understand what exactly you are doing, and to some degree, why.[/quote']

I'm sure I'm doing it wrong, but as for the why... Basically I was trying to learn about configs while also trying to change RH's default sound for his M-4s to the vanilla sound (so it would inherit any sound mod I might be using). The good news is I learned about inheritance and got it to work for a couple of addon configs, but not for others.

If you Unrap an bin and edit the cpp, you dont have to turn it into a .BIN again. Once inside a PBO, it will work.

Are you saving virtually the same config/bin in one PBO, while leaving the original config/bin in another PBO? ......... in that case it will never work properly.

RH addons have a "unit" .pbo (in this case a weapon) and a "config" .pbo. I was playing with the config .pbo which has nothing in it but the config.bin. I tried compiling it back two different ways. The first was as I described (Unrap->.cpp->.bin). Then I just tried PBOViewing it to the .bin file and then re-BinPBO it back to a .pbo without ANY modifications to test the process. Even that didn't work. I think I tried what you recommended once (leave it as a .cpp), but no luck, but by that time in the process, as I said above, it might not matter, since it was failing as a .bin

That pbo folder hasn´t got a *pboprefix* file sitting in it´s root by any chance?

If so, delete it and then repack.

Nope. The only thing in the folder is "config.bin."

As Gnat said, it´s not the most common or recommended approach you are doing it.

In ArmA editing there´s mostly one way to do it right, but a gazillion to make it wrong - up until you´ve found most of the ways it doesn´t work, you´re screwed :o

No doubt. I think the same was the case in OFP. So if it's not the most recommended, I take it Eliteness is? Just curious on another tack to take.

>I get an error that says the "side by side configuration is incorrect."

you need a copy of vcredist_x86.exe

https://dev-heaven.net/projects/mikero-pbodll/files

this is in the dll readme and occurs for some people's systems where this file isn't present.

I just double checked the readme of dePBO and it doesn't say this. I grabbed it from dev-heaven, so I should have the latest version. That said, I'll grab what you posted and have a look. Thanks for the pointer.

>same directory as Eliteness or in the systemwow64 folder

as the readme says. put it in system32, or same directory.

Ahh, okay. I put it in the 64 folder because a thread here said if you are running a 64 bit OS (I'm running Win7 64), to put it in a system64 folder (which I didn't have). I've moved it over to the system32 folder and with the above mentioned file, I'll give it another go.

>DISCLAIMER: I'm messing with people's .pbo files

there is nothing dishonorable in that. breaking open pbo's to see what the hell's in there, let alone learning from what IS in there, is a time honored practice.

I appreciate your perspective. I just wanted to make sure that people (specifically RobertHammer) knew I wasn't trying to steal his work and re-release it, just playing around and learning.

A pbo is a convenient distribution method. It's intention is identical to zip or rar. it's simply packaged content. If you weren't meant to break them open, they'd be encrypted.

-PBOView to extract

-Unrap.exe to get to a readable .cpp

-BinTools to re-bin the config files.

and blah blah. Eliteness covers all those bases. But, i encourage you to work with all these different tools that do the same thing so you get a handle on their strengths and weaknesses and, in the process come to understand the buzzwords each one uses to do basically, the same stuff.

The crippling factor for the above non-bis tools (and other tools of their kind) is that when the formats change, and trust me, they change, often. You just hope a new version will come along soon. Using the dll approach, the exe almost never changes, while the dll always reflects the latest engine improvements. backward compatible to the very first CWC demo

Enjoy

Thanks for the help. I'll post back here after I play with it a bit more. Really appreciate the help from all.

[gatordev 219]

To Mikero,

Thanks for the help. I got Eliteness to run with the added .exe you linked to.

An update... I was able "dePbo" with Eliteness (I know it's not quite the same thing in that program) and then immediately rePBO it and it worked in game. As soon as I took out the references to .wss files in the config, it wouldn't show up in game. What's baffling me is that doing the same thing with two other addons does work. Maybe I'm just reaching a bridge too far.

[max power 21]

I think you can probably do without unbinarizing all kinds of stuff. There are a few community made resources for browsing configs.

PvPScene has a bunch of resources in his Community Modding Bible, including a complete config.

Sickboy hosts the Six Config Browser that allows you to browse configs by entity (vehicle, weapon, ammo, etc).

With respect to what Mikero says about depboing and debinarizing, the best practice is to respect the license of the work you're investigating, or to get special permission to break it. I know what TOP is saying and / or doing, and I'm not here to puff my chest up and run my mouth. I'm making a general comment about practices. Besides, using those tools are much more user friendly than dealing with depbo'd addons imo. Again, IMO, they do a great job of fulfilling the need that people might depbo addons to satisfy.

Edited March 6, 2012 by Max Power

[[frl]myke 14]

I don't want to jump on the discussion about "what you should and what not" regarding permission and intelectual property. Starting a discussion would probably end in a flamewar which doesn't help anyone.

Instead, let me just share some experiances i've made so far.

So far, asking for permission and maybe unPBO'ed, unbinarized material helped me a lot. Not only in receiving permissions and material but also with the direct contact with the developer of scripts and addon, they could point me some interesing informations i wouldn't have gathered by just looking at their stuff. So i got more than "just" a bunch of code but also some more valuable background.

Also i gained some respect just because i've asked. I've received material that i probably wouldn't have got if i were known as someone who just "rips stuff apart". Regardless if it's correct or not, there are people who do care about and who do have a lot of coding/modelling knowledge.

So even if it's "just for yourself to learn", i suggest you get in contact with the author as you could only win.

[[aps]gnat 28]

Yes, Two sides to every argument ........ same as theres at least 2 types of mod'ers in a comunity ;)

I generally only consider p3d's off-limits, they unfotunately can be abused (potentially for financial gain) OUTSIDE of BIS games.

Anyhow .... nuf said.

[gatordev 219]

I think you can probably do without unbinarizing all kinds of stuff.

I actually haven't been doing that since using Eliteness, since it lets me edit the file within the program. Still, same issues. The addon doesn't show up in game once I modify a single thing for that particular one.

As for the "moral" question of digging around in .pbo files... Copy all guys. I understand what you're saying and the subtleties of asking the makers. I may have already exceeded my capabilities, but I get what you all are saying about how the community helps itself by being honest with each other.

Thanks for the resources.