Talk:PBOPREFIX

• The benefits section still contains too many assumptions and is lacking some critical detail about what it actually does and what it affects. Whenever I use it, my files are not found. I'm using cpbo.
  • does it prefix (or substitute parts of) path names used by scripting commands like execVM or image locations for rscTitles or file locations for #include (in config.cpp, resources or any scripts)? Or is the base folder (containing the addon name) still always required in all file paths?
  • does this help make scripts more transferable between missions and addons with regard to relative folder structures? Currently, after I copy scripts across from a test mission to the addon, I still need to adjust the base folder for all paths. I kind of figured this $PBOPREFIX$ would solve that?

• the use of a P: drive is optional and I don't use it, so it might be better to explain why it's recommended. I assume there's some tool dependency/default handling for that drive.

• Am I right to say that using this specific format below means that the mod folder is then hard-coded? eg. you cannot move your pbo to another 'common' mod folder?

x\myMod\addons\myAddon

• Is this first example correct or should it be the second example below (or are both valid)?

myMod\myAddon

myMod\addons\myAddon ?

• Glad to see you clarified the term 'namespace' in this situation, given that Arma 2 now has it's own definition for variable namespaces. I hope it's the correct term though.

Any further details would be appreciated.

Dr Eyeball 16:00, 11 January 2010 (CET)

Good points.

First of all most aspect of path addressing in ArmA know some form of relative and/or absolute addressing.
Second aspect is in terms of PBO containers, without a prefix definition the pbo name is used as base path.

In this case if you rename the PBO file, it will break the addon if it uses any absolute path definitions.
Like in cpp, p3d, rvmat, sqf, etc files.

With a prefix the pbo name is simply an identifier, yet for internal addressing the prefix is used.

A prefix would save you from changing path yes. That said most parts can be addressed relative like

#include "h\cfgPatches.hpp"

execVM "server\init.sqf"

I don't recall where relative addressing does not work. It does not work in several instances though.
As always BI is pretty inconsistent and in the end inflexible ..

A P drive is most important for p3d and PEW/WRP business.
The benefit in general is to get a clean place for buildings your addons.
Unless you mess up your P drive. Easy to create a Q, T, R, S drive if needed.
Junctions and sym links are neat tools to rewrite files/folders to exist in multiple places. See DH article.

Prefix have no relation to hard-coding. Quite the contrary. The give you more flexibility.
At the same you can use macros to define path once inside configs or scripts.
CBA has macros and made examples in it.

Subfolders are used to separate content/workspaces. You can use any given setup.
For unpacked data setup you need your data with a path and prefix of

path\addons\myAddon

simply as addons are only loaded inside a folder called addons. It does not matter
if the addon is a folder (unpacked) or a PBO (simple container).

Hope that helps. --.kju 17:05, 11 January 2010 (CET)