$PBOPREFIX$, Config.cpp and #include woes

[ruebe]

Hi

I'm switching my workflow for my RUBE script library/pack. Instead of using the global Script-folder (which was nice until I needed to have some dialogs), I'm going the route of an addon/script pack hybrid like in mando_missles; yet I have no intention of actually making an addon - it's only about workflow and not having to copy my library into all the mission folders...

filesystem:

• .../ArmA2/RUBE/
  
  This is my working directory, named like my addon/pboprefix to make `file patching` work (it does work). All files are in here, like:
  
  
  
  • .../ArmA2/RUBE/$PBOPREFIX$
  • .../ArmA2/RUBE/config.cpp
  • .../ArmA2/RUBE/core.hpp
  
  
  ... and all the sub-folders with all the stuff as usual. The content of $PBOPREFIX$ is simply: "RUBE", a single line. No whitespace.
  
  
• .../ArmA2/@RUBE/AddOns/RUBE.pbo
  
  This is where I move the pboed addon so that `file patching` works (starting arma with -mod=...;@RUBE). I create the pbo with an ant script that pbos the .../ArmA2/RUBE/ folder with mikeros MakePbo1.79.

ArmA2, of course, is the games root-folder.

This all runs very well (my library loads, file patching works too and even the init-script runs if I place down the defined logic, so that path works?!) - we'ren't it for the include statements in config.cpp (see below).

The following line:

#include <\RUBE\core.hpp>

does not work and MakePbo fails with:

Line 13 Cannot include file
Result: 15

config.cpp (in full):
Spoiler:

show spoiler

class CfgPatches
{
	class RUBE_library
	{
		units[] ={};
		weapons[] ={};
		requiredAddons[] = {};
		requiredVersion  = 0.1;
		version          = 0.1;
	};
};

#include <\RUBE\core.hpp>
#include <\RUBE\common.hpp>

class RscTitles
{
#include <\RUBE\rsctitles.hpp>
};

class CfgSounds
{
#include <\RUBE\sounds.hpp>	
};

class CfgVehicleClasses
{
	class RUBE_Logics
	{
		displayName = "RUBE Logics";
	};
};

class CfgVehicles
{
	class Logic;
	class RUBE_Library : Logic
	{
		vehicleClass = "RUBE_Logics";
		displayName = "RUBE Library";
		model = "\ca\weapons\empty";
		icon = "\ca\ui\data\icon_functions_ca.paa";
		
		class EventHandlers
		{
			init = "_this execVM '\RUBE\init.sqf'"; 
		};	
	};
};

On the other hand:

#include <..\RUBE\core.hpp>

or simply

#include <core.hpp>

works (of course; config.cpp is in the same directory), the pbo gets generated and the stuff will be included. The problem is, that these paths are only fine for an addon-version. But this wouldn't work for my intended script-pack, and these paths would need to be altered (for the description.ext file).

In mando_missles, this:

#include <\mando_missiles\mando_missile.h>

seems to work. And that's the form I'm after. So what am I missing? What could be my problem?

thanks,
rübe

[.kju [PvPscene]]

You are aware that config space is only loaded on game startup and cannot be modified on runtime?

[Sickboy]

The RUBE folder must be in the root of a drive for makepbo to work with the absolute path "\RUBE".

e.g put RUBE folder (can be symlink) on P: drive (so you get P:\RUBE) and then makePbo it from there.

If your pboprefix would be x\abc\RUBE then the path on P: should be P:\x\abc\RUBE instead.

[ruebe]

The RUBE folder must be in the root of a drive for makepbo to work with the absolute path "\RUBE".

Of course! The P: drive! I've actually already copied my RUBE folder to the P: drive, but it didn't occur to me that I have to build/makePBO it from there... DOH!
So my working directory is now P:/RUBE and that directory gets pboed with makepbo; $PBOPREFIX$ thus contains "RUBE" and now it works as desired.

e.g put RUBE folder (can be symlink) on P: drive (so you get P:\RUBE) and then makePbo it from there.

P:/RUBE is now my "real" working directory and to make "file patching" work again, I've created a junction from P:/RUBE to .../ArmA2/RUBE with the Link Shell Extension (available here for anyone interested).



Thanks you guys and tweak on!,
rübe

[.kju [PvPscene]]

1.79
added -$ option to *potentially* not insert a pboprefix in the header

In other words the prefix is the pbo name. The pbo name is the top most folder supplied to makePbo.

---

See also DH wiki for virtual folders:
http://dev-heaven.net/projects/heave...ders_and_files

[Mikero]

sickboy and pvpscene have stated it pretty clearly. There is a confusing disconnect between #includes vs any other form of file reference in arma (and ofp)

#includes *can* use relative addressing, whereas everything else (model = , execVm etc) are \RootPrefix

#includes *tend* to be used by mission makers and scripters, wheras modellers and island makers *must* use \prefix roots. mission makers have no issues with prefix roots because there aren't any.

it's when those two worlds cross, confusion hits. The best way to use #includes is ALWAYS relative addressing (never use a \hard path reference). these are garanteed to work, under all circumstances.

For addons, whatever folder it is you are packing, from wherever you are packing (including somewhere on the c: drive, should you wish to) *that* folder is *potentially* the \prefixRoot

makepbo -$ allows you this (unusual) option. You are in effect telling the arma engine that NameOfPbo IS the prefix. This is an ofp compatibility option. And is very, very easy to understand for the user. Everything (s)he addresses in that pbo, is, via it's pboname.

However, it's not an option the moment you go anywhere near islands. They *must* have full access to all models, correctly placed, on a 'p:' drive

for this reason, the default behaviour of makepbo is that the \prefixRoot is the full command\line\path\to\the\folder

it only inserts into the pbo whatever it finds in the folder (and it's children) but 'understands' that the prefixRoot to all these things is, as stated, on the command line.

as a convenience and alternative to above, users can simply point to the folder any way they like, but, the \prefixRoot is contained eitehr in $PBOPREFIX$ file, OR, is stated on the command line with -P \Prefix

the last option, while 'simple' for basic addon makers, is just not usable for island makers

I hope this helps, rather than confuse.