PBO File Format – Talk

Just in case it has been overlooked, the links in the Bibliography at the end of this document are no longer valid at this time.

Planck 12:29, 13 July 2006 (CEST)

Binary

I removed binary = executable sentence, because it was confusing. Binary does not necessarily mean executable.

Moreover, I itend to move the whole discussion about binary config into the config.bin page.

--Suma 23:12, 18 July 2006 (CEST) Insert non-formatted text here

Addons in Folders = possible

I've used addons in folders since years, here's how i proceed : The folder must be (as far as i know) in Operation Flashpoint main directory, by convention i'll refer to it as 'MyAddon\', referring to the addon as 'MyAddon' and to the pbo file as 'MyAddon.pbo'

Only the pbo's with a config will need something more. That is, the config in 'MyAddon\' will not be aknowledged by the engine. Either the class definitions are in the main config ('bin/config') in the case of a total conversion mod for instance, or in another pbo (most often times the 'MyAddon.pbo') located in a '[mod\]addons\' folder as any other regular addon. In the case of a text config in 'MyAddon.pbo', usually config.CPP, this config may only contain an #include line linking to 'MyAddon\textfile.hpp' for instance (where textfile.hpp is actually in 'MyAddon\' and has the exact content the regular config would have) or series of #include lines. There's some side effects though as the content of 'MyAddon\' as if it were in a pbo in 'OFP\Addons\' as opposed to in a mod's 'Addons\' folder. Which means it could conflict with a different version of 'MyAddon.pbo' in a mod. Nevertheless, if one keeps track of what he's got in his OFP's main directory and cleans it up after they've finished beta testing, it's really something that eases the process of creating, modifying and testing an addon a lot.

I am not too comfortable with my level of literary english and pedagogy to edit an entire article, but i thought it was worth being mentioned in the discussion about "Pbo File Format", in case someone wants to amend the introduction and write or help me in writing the article.

--Lupus[WD] 02:41, 19 July 2006 (CEST)

Hi lupus, Please send me a small example addon of what you are saying here (mikero@norfolk.nf) so that i don't mis-interpret you. We can work on your article together. What you are saying needs a link, (a separate page) to the main text of this article.

--ook? 00:40, 20 July 2006 (CEST)

What he is referring to is the ability to use plain-file unpacked content in your game folder, rather than packed pbo's in your addons folder.

For example, let's suppose you have OFP installed to

c:\ofp\

Data.pbo and Data3d.pbo would normally be located in

c:\ofp\dta 

However, you can also unpack those pbo's, and place the folders in the ofp chroot folder, so you have

c:\ofp\data\(*.pa*)
c:\ofp\data3d\(*.p3d)

Doing this can help the development process of a variety of content such as maps, missions, models, textures, and so on. The only limitation is that configs must be located in a pbo. You can have a pbo and a chroot folder both with the same name, however that is ill-advised as it's easy to confuse which content is being accessed. The one exception to this is of course the core configs located in c:\ofp\bin.

One recommendation in line with this is the content organization model similar to what's used in VBS and other mod's projects. Projects would be divided into a variety of packages, such as projectc.pbo for configs, projects.pbo for scripts, projectt.pbo for textures, projectd.pbo for models, and projectw.pbo for maps, or something similar. This would allow you to constantly modify small pieces of content and test without having to make significant repacking, and would also improve inter-team distribution, and patchability.

Shinraiden 02:06, 20 July 2006 (CEST)

configs must be located in a pbo

which, if i've understood correctly can be 'got round' by having a single line in it

#include "\somewhere\blah"

a quick 'n dirty way of checking that models look good bad or indifferent 'real time' is a good thing (tm) if you can save on the tedious process of making a pbo for each tweak. The only other important ability is to tweak that config.cpp. Taken as a separate issue, ie concentrating on tweaking the config (as opposed to making models), the whole point of the excercise above would be pointless if you had to persistently create a pbo, for that config. I can 'see' where a #include would do the job.

--ook? 03:15, 20 July 2006 (CEST)

Well on that note though all content other than configs may be modified while the game is running, but you have to completely restart the game to change the configs, so I haven't really bothered with externalizing them in that fashion. There's also the matter of < and > vs " and " and your absolute pathing. It might be worthwhile to fork this discussion into a detailed page on setting up a system for content development.

Shinraiden 03:38, 20 July 2006 (CEST)

damn good idea, I'll leave you to move this talk page elsewhere (coz I don't know how to) <grin>