How to use #include in a description.ext

[dr. seltsam]

[Walter_E_Kurtz]

I think you can only use #include in files that are actually processed in some manner - this means config.cpp and resource.cpp. I take cpp to stand for C++ (C plus plus).

You would have to put ALL possible sounds / resources in the description.ext and modify your script to pick the correct one.

[kju]

include in .ext works fine (at least a2+, yet ofp should be no different).

missionName.worldTag\subFolder\myFile.hpp

#include "subfolder\myFile.hpp"

[haroon1992]

My experience in ArmA 2 shows that(maybe the same for OFP) :


- You DO NOT need a semicolon at the end of the line
- the target .hpp file MUST be either in the MAIN directory or SUB-FOLDER of the mission.
For example :

Code: [Select]

#include "subFolder1\myFile.hpp" will work
but

Code: [Select]

#include "subFolder1\folder1\myFile.hpp" will CRASH the game

If you've already learnt those things,they may still be useful for others.
---------------------------------------------------------------------------------
And you better define the CfgSounds and others in the description.ext and just put the contents in a seperate file.

Example :

description.ext

Code: [Select]

class CfgSounds
{
#include "sound\mySounds.hpp"
};
mySounds.hpp

Code: [Select]

class sound1
{
sound1 properties here
};
class sound2
{
sound2 properties here
};

[faguss]

What file extension do i need?

Extension does not matter. It's part of the name. If you'll paint black dude in white he may look white but still be black dude.

processed in some manner

What the hell does that mean? Resource and config are simple ANSI text files. Sorry, I missunderstood. Description is processed in the same way as config and resource. And cpp stands for C preprocessor.

My experience in ArmA 2

This is not ARMA2. In OFP it's different. Source directory is game root folder. So to include file from mission folder you would have go all the way up:

Code: [Select]

#include "Users\<your name>\missions\<your mission>\<file>

[haroon1992]

Oh I didn't realized that....
I was just telling what I found in ARMA 2 and I thought they may still be same.

if the mission has this code in its description.ext ,
#include "Users\missionCreator\missions\mission1\config1.hpp"
and its being packed (pbo'ed) and uploaded to online. then downloaded by player...

Will that code still work on the player's machine? because the path will not be the same!

Regards,
Haroon1992

[faguss]

It's not a problem assuming that mission ends up where it supposed to be: \Operation Flashpoint\Missions\.
Then the code would be:

Code: [Select]

#include "missions\__cur_sp.<island>\<file name>"
For multiplayer:

Code: [Select]

#include "mpmissions\__cur_mp.<island>\<file name>"

[dr. seltsam]

[Mr.Peanut]

max,

All an include statement does is literally cut and paste the text from one file into another.

Anything paths and upper case letters inside the pbo mission will be properly converted by the linux ded server i.e. \ changed to / and upper case converted to lower case. I don't know anything about the include path, but if no one has used it before in other missions there may be a reason.

Try using an #include for a nonexistent file and see if it crashes OFP. If not then you can supply all three include possibilities. And pray like hell no one renames your mission pbo.

Can i have such a file included in the description.ext with other cfgSounds and rscTitles already existing in the description.ext?

This you can test. Make two separate cfgSounds in one description.ext and see if sounds get properly defined. I suspect they will not.

[Walter_E_Kurtz]

Dr. Seltsam,
   #include is a pre-processor command, so see if you can make sense of the BIKI on the subject.

All I can say is that I have only ever encountered such pre-processor commands with addons (and mods) in the config.

Going back to your original question, try creating an addon called Zombie.pbo, then your paths would be correct and you could see if the #include worked in the mission:

#include "Zombie\Zombie_Config.txt"

[Mr.Peanut]

For an addon don't you have to start the path with the slash? i.e.

Code: [Select]

#include "\Zombie\Zombie_Config.txt"

[dr. seltsam]

I tried several versions by now..
It works if i write the path beginning from the OFP main directory to the description.ext:

Code: [Select]

#include "Users\myName\missions\Demo_Zombie.Intro\Zombie\Zombie_Config.hpp"

But this is not a real option, it has to work with a relative path beginning from the mission folder. Can anybody provide a very simple made demo mission with an #include statement only to prove the concept? I would be able to copy this technique and build up my Config.hpp or Config.h ?? from it into my mission.

[Mr.Peanut]

max,
it sounds like what you are trying to do (define resources) should be done in the addon itself, not the mission. is there a reason it has to be in the mission?

[Walter_E_Kurtz]

My emphasis; quoting from here.

We never used #include in description.ext and I am therefore unable to tell you how it should work. I would expect there will be problems with the paths where preprocessor looks for the included files. I assume the current directory during description.ext loading is not where description.ext is, but in the OFP folder (where exe is).

Perhaps someone with an understanding of C/C++ could manipulate the __FILE__ command into outputting the path to your mission. I couldn't get it to work.

Similarly, efforts at using ..\ for a relative path also failed.

[faguss]

@Faguss:
When i test the mission in the editor the folder is:
When the mission is saved to multiplayer or (my guess is) saved on a dedicated server:

Take a look again on the code I've wrote. In the <brackets> put custom text. Sorry, I can't make it simpler.

Try using an #include for a nonexistent file and see if it crashes OFP

Of course it will crash as you're trying to work with something that does not exist.

pray like hell no one renames your mission pbo.

Doesn't matter as long as the island extension stays the same.

For an addon don't you have to start the path with the slash?

No. Why the idea? Never tested?

But this is not a real option, it has to work with a relative path beginning from the mission folder

There is no such method and there won't be. Get it over with.

manipulate the __FILE__ command

OFP does not support such macros. They are less of a command and more of a constant variable.

using ..\

Why would you want to leave the game folder?

[Mr.Peanut]

No. Why the idea? Never tested?

Why the idea? Because in addons I have looked at paths start with a backslash. You may have noticed also that my comment ended with a question mark. This was to indicate that it was a question.

My next statement will not end with a question mark because it is not a question. text deleted

[faguss]

Because in addons I have looked at paths start with a backslash.

Then I guess you were checking addons for the wrong game because in OFP if you'll start include path with backslash then the game will crash.

text deleted

[Mr.Peanut]

Not an addon for the wrong game, but extrapolating from the path required for everything else in addons, but now obviously excluding include statement paths.  Hence the question mark at the end of my original comment.
text deleted

[bedges]

Okay gents, this thread has fallen below OFPEC's usual standard. Please drop the bickering tone, and stay on topic.

[dr. seltsam]

is there a reason it has to be in the mission?

Code: [Select]

#include "Users\myName\missions\Demo_Zombie.Intro\Zombie\Zombie_Config.hpp"
... This works in the editor, and.. after i exported the mission to multiplayer (it was in the folder MPMissions then) it still worked !!! Very nice. My guess is that it will also work on a dedicated server then. So the preprocessing of the description.ext is done when i load a mission into the editor?

Well.. the drawback is.. i cannot have class cfgSounds or class rscTitles twice. I can have it in the Zombie_Config.hpp or

[Walter_E_Kurtz]

I feel you still ought to double-check by either deleting or renaming the un-exported version.

Yes, pre-processing of description.ext is performed on loading the mission in the editor and only on loading - if you make any changes to description.ext you have to re-load to see them, you cannot just preview.

[haroon1992]

if you make any changes to description.ext you have to re-load to see them, you cannot just preview.

For me, I just "Save" the game to make the game reconize the changes in the description.ext.
And its a better and safer way, in case you've done something stupid in the description.ext and the game has crashed.


Regards,
Haroon1992

[Mr.Peanut]

I am forever indebted to this thread and Faguss' answers. Helped me solve a broken addon cross-dependency on a linux ded server.