Feature #2103

Support for virtual-file system includes during rapification

Added by Sickboy over 6 years ago. Updated over 6 years ago.

Status:Rejected Start date:06/16/2009
Priority:Normal Due date:
Assignee:Sickboy % Done:


Target version:Rejected
Affected Version:


I use for instance: #include "\x\cba\addons\main\script_macros_common.hpp" inside: x\six\addons\main\script_macros.hpp
(which in turn is included in x\six\addons\main\script_component.hpp which in turn is included in x\six\addons\main\config.cpp (among many others)
Rapifying main\config.cpp gives an error, because #include is no absolute path, nor relative path.

In this instance, it is relative to P:\ ('x' is located in P:\), however, I also have 'x' mounted in my arma folder, and then it is: C:\_Games\ArmA\x

Thus probably requires a -PROJECT setting like BinPBO?


Updated by mikero over 6 years ago

"because #include is no absolute path, nor relative path."

from the engine's perspective ANYTHING with a preceding slash, is, absolute path. It is absolute to the start of the pbo prefix tree.

the fact that this file might exist in c:\some\where\any\where\at\all has no significance to the engine. It never 'sees' that file because it is inside a pbo when the engine goes sniffing.

ALL path statements (of any kind) inside arma are either relative to where they are encountered in a pbo, or, an \absolute reference to A pbo, (often, and badly, the same pbo as where the statement is encountered).

As a side note, p3d files don't using relative addressing at all, hence all the hair tairing frustration when moving them about.

One way or other, you must build the pbo prefix tree as the engine would see it. Conveniently, this can be via the use of a subst drive, where, every \reference to a pbo, MUST be at the start of the subst drive root. (to simulate the engine's virtual tree), this almost certainly, means you have to explode out the entire Arma addons folder to 'there' along with any of your creations.

It's a matter of convenience that irrespective of how many addons you create, you only build the arma ca folder in the subst drive, once. From then, it's there for all your (future) creations. Ditto Arma2, Ditto Queens Gambit

Similarly, it is is quite likely than one of your addons will reference one of your others. It is therefore, again, a matter of convenience that all your creations start in the root subst drive. Forever.

The sobering fact is, no matter where you want to sprinkle YOUR addons, you are going to have to create a very large and very substantial ca\folder\tree.

Relative to that, your addon is a trifle, and you might just as well put it in the SAME tree. (eg subst drive)


P:\CA\......... the official arma stuff

For this reason, i do not see any value in providing a 'project' file, or a chain list of 'where to find #includes' when the simple (and quite disciplined) mechanism above works well.

Secondly, the moment you introduce a chain list (of where to find addons sprinkled all over your hard drive) it invites errors. There is no guarantee with that method of wyswig. It does not necessarily follow that the #include path(s) ARE, as the engine would see them.

Thirdly, the subst drive forces some discipline it what you are doing. Instead of scattering folders in my documents, a D: drive, and 'something i dowloaded'. you are forced to see the folder structure as the engine sees it, rather than (an often encountered error) #include "c\something"

Updated by mikero over 6 years ago

  • Status changed from New to Rejected
  • Assignee set to mikero
  • Target version set to Rejected

unless there's a substantive reason to continue with this, i have rejected the ticket.

Updated by kju over 6 years ago

  • Assignee changed from mikero to Sickboy

Updated by Sickboy over 6 years ago

Jep, you fixed it over the course of the past weeks. My suggestion was way before your app working perfectly with these includes :)

Also available in: Atom PDF