freda

Hi Folks, am embarrased that I can't find the original topic on this. Salisin figures prominently but damned if I can find the original thread. I have made a depbo.dll avaialable at http://www.ofpec.com/editors/list.php?show=pending or http://andrew.nf/ofp/tools/ Source code supplied on request the dll will decode the usual compressed folders and things as well as decrypt so-called 'encrypted' mission sqm's and fps files. You can attach it to any C++ or visual basic app you care to make and should solve the eternal issue of dicovering, yet alone writing, a decompressor for pbo files. I have fully credited original code suppliers in the various headers in the rar file above and apologise to those of you for not doing so here. enjoy

Latest eliteness is here http://andrew.nf/ofp/tools/eliteness2.07.rar fixes above memory problem and a few more 'features' i remain unaware of array issues mentioned early in this thread.

Hi Fideco send me the details please, sooner, the better. mike.andrew on skype [email protected] or a pm here thanks

@Phaeden I would have to see the text file concerned. Send it to me via skype or my email. Regardless, this is a bug, and shouldn't be happening.

this is news to me. Since Kegs took the information directly from me, i'm surprised. Details please. again, incorrect. Elitness2.04.rar rapification occurs for any class text, with the option to generate either arma/elite or ofp style encoding. In fact, this is the only significant difference between our tools. Eliteness rapifies, kegs, currently does not.

this is news to me. Since Kegs took the information directly from me, i'm surprised. Details please. again, incorrect. Elitness2.04.rar rapification occurs for any class text, with the option to generate either arma/elite or ofp style encoding. In fact, this is the only significant difference between our tools. Eliteness rapifies, kegs, currently does not.

Eliteness is in effect the gui version of keg's tools. A more one-stop shop version. Developed separately of course, but Kegs and I achieve same ends. when you rapify (binarise) the text file you see in the window, you need to give it a destination name, such as config.bin. And, guggy is right, a config.cpp if present in the same pbo will take precedence over a config.bin. However, using the options panel in eliteness it will rename this file to config.cpp.txt to avoid the issue.

what appeals about this 'patch' is that it is merely allowing an author to 'look inside' the official addons and use otherwise unselectable models (except by camcreate) There's nothing new in that, since the almost-mandatory editorUpgrade102 does much the same thing for ofp from the author's perspective. the difference is, this 'addon' is not required by the end user. And that, is clever. I think you need to make it 1000% percent clear to the author that this patch will NOT alter or modify the bis addons in any way. That, would be scary, and that is the impression given. As for the G85_ addon. It too has it's place. It's very early days for Armed Assault and a learning curve for everyone. G85 is a good start, that's all. No doubt, it will mature. There are self evident limitations to how far this patch approach can be taken, vs the need to have an addon downloaded for the player, but clever it is, and worthy. What I believe the main point here is, the message going out to the community is that oem development, 3rd party everything is already underway for Armed Assault.

Obviously not a total answer, but you might be interested in this ofpec have been doing this style as above for a few years now.

Right. Enough conjecture and speculation. here is the bis wiki file format pbo. with the correct, non polluted info on the subject. here is the statement ArmA Pbo Armed Assault Pbo's are currently identical in makeup as Operation Flashpoint Elite Pbo's. what this means is the information initially added to resistance headers has changed in text, but NOT, in structure. what this means is any tool that opens a resistance style pbo will open an arma pbo. Period. The corrolory to this is of course that the tool itself must work well to begin with. the content of that pbo is irrelevent (be it different textures or whatever, where different, and if different) the fact remains, the pbo and the means of extracting the files within it, is identical.

this is a great tool. I am using every single day. It does have one nasty 'undocumented feature', if you delete something from the list of entries, if you're unfortunate enough to have the unpacked pbo folder in the same path, winpbo deletes that entire folder! (separate to it just deleting one of it's own entries) A nasty bug, but this is a fabulous tool.

Looks like a beta road test paid off Mr N

I would have to add MakePBo functionality first. btw, I did find one major quirk in your source and that was, often, the decompressor would extract one byte less than the stated file size, causing a checksum fail. I dunno why that would be. and, I have no idea what the difference is between resistance vs older 'pbos'. Works on both and I can't see what it is.

>this might a good place where your tool could get very handy ! thanks for that I understand what pboReplace does, and it's my view that this sort of editing should not be done within a pbo file (ie direct manipulation). It _should_ be expanded out, and worked on 'properly' which the replacer currently does (albeit with bugz) Originally I wrote AddonScanner to only inspect expanded files (rather than pbo's) and since source is supplied, it would be relatively easy for someone to modify it back, or more purposefuly, to snaffle the subroutines and incorporate them into pboReplacer eg. The dll itself would not be suitable for this task because, ultimately, the changes made would have to be written back to a pbo file, and there is no (current) dll to do that. Unless of course one of the side effects of pboReplacer was, that if could grab a pbo and automatically extract it. so, duh, what am I going on about

very comfortable with gpl, the source is now, also provided on the same site

@Gnat grab the addonscanner2 from the same site as above, it sniffs at mission.sqms and will, at the very least, give you some better ideas than my poor effort (naturally, it uses the dll) >This and may other things possible _precisely_ that's the intention. To be able to quickly and easily dream up a Visual Basic quick 'n dirty to do 'something' without the agony of decompressing. @airblade >detect addons that would have conflicts during the game nope. >and help with game crashing problems? definitely not. it is there for authors prior to publishing to be sure they got ALL their godamn addons listed so we poor players can download ALL of them, not just the ones they remember it is there for players to check they have all the addons required for the campaign/mission they just downloaded _before_ starting flashpoint and crashing to the desktop halfway thru the mission.

God, how bad is that. I can't even get your name right salisin !!! umm, from memory, the main issues were a severe lack of malloc freeing. Large pools were created of ultimately innaccessible data (because it had been 'used' and ptr discarded), this became noticeable on huge campaigns like fury. Admittedly C++ came to the rescue there. Am I talking to the person with the ~erik website? Because if so, the code supplied from there solved all mysteries for me and is a C++ version of it (modified extensively to DLL) The only 'bug' I found was in some strange decompression signatures, particularly 'product' on some very few pbo's. The depbo (not the bincpp) didn't know what to do with them. There were no showstoppers in either of the source codes, just some odd quirks. Basically, I'm just damn thrilled to have this dll now, because it opens up a Pandora's box of possibilites using visual basic (which while poor and slow has the best quick 'n dirty forms maker out there) If you want a sneak view of how powerful this option now is, grab the addonscanner2 from the same site which sniffs pbo's for addons in the mission.sqm. Am just waiting now for a bit of feedback from various sites that there's no major bugz, and then I'll release the source code as well. If you want an early copy, you know what to do i guess.... If I've got the right person, Erik Gävert, <email suppressed> let me thank you right now for that code source.

I dont know if this is the 'correct' area to post this but Gnat was requesting an addon to this current app to sniff inside pbo files. I have supplied a depbo.dll that can be attached to C++ AND visual basic programs to avoid the need to do all this again and again and again... it understands all about so-called 'encrypted' mission.sqm's and fps files. http://www.ofpec.com/editors/list.php?show=pending or http://andrew.nf/ofp/tools/ source supplied on request

fixed

Hello people. thank you for this interesting map and Coin. I'm enjoying the map a lot, the textures and detalils seem 'just right', love the placenames. As an attempt to really putting Coin to work, it's good, isnt it. I'm finding the replay aspect a little predictable and the new controls a bit quirky for a newbie like me, but definitely a winner. The predictability isn't in the randomness of which mission, but rather the now boring, setpiece manouvers to get to the next mission. This becomes tiresome. As far as the map is concerned: a niggle. It's far too big. It's a tough one to map-navigate with. The ofp design doesn't cater for it at all well, a basic shrink, and hope you can move that far, stuff. Perhaps (and I hope) the next mission class will restrict itself to a section of the entire map.

am a bit confuzed too. this (the non beta non rc 1.96) is a 12meg download, wheras the 'patches' i'm used to are circa 2 meg and involve the .exe only. short of going thru all the 1.96 messages in the forum, what's the structure here? beta -> 'release candidate' -> 'real thing', and is this what we'll normally see in future? Not complaining, just want to get my head around it. If it's "official" what does that actually mean? all future purchases of OFP resistance CD (eg) will be 1.96? is that how it's working?

soldiers in your squad cannot re-arm their weapons. Eg, a soldier taking a PK cannot then get an extra PK mag, a LAW soldier cannot get another LAW after using one, eg and etc. prior to this bug, it was a bl**dy nuisance getting a soldier armed with a pk or rpg, you had to additionally, repeatedly keep telling him to take another round, or charge.

it is most definitely and absolutely not present in 1.91. add-ons or pristine, this bug exists in 1.94b. It makes playing some tankfests 'interesting' <grin> it was introduced as part of the crash prevention that occurred if you told your soldier to drop a LAW (in 1.91) There is, or was, a related bug in 1.91 which obviously cannot now be tested. teliing a standard soldier to pick up a pk (eg) needed you to tell him to repeatedly pick up the ammo too. Otherwise he would only grab a single magazine. Duh.