The only adon you will ever need ?

[Roni]

Hi All

Sorry for the cryptic header, but now that I have your attention I have an idea related to the use (and hopeful abuse !) of the description.ext file.

I have been wracking my brain trying to work out whether or not we can use the ability of the description.ext file to define new sounds etc to define new anythings - weapons, vehicles, animations, configs, etc.  So far my research has come up in the negative.

I started another thread about this topic some time ago and after lots of frustrating near misses I basically discovered that the description.ext file is a "special" file that has been allowed a very limited ability define sound configs only, but not anything else.

Now for the query !

Does anyone know much about the underlying programming language of configs ?  I believe that it is a form of C (C++ ?), if it is then is it possible to call files using some sort of command, say in a config ?

In other words, even though description.ext is not allowed to define or call non sound configs, could a file call from a config do it ?  Could I have just ONE addon consisting of (say) a black box, which whenever it is placed on the map, all it does is call externalConfig.cpp, and have this config define new vehicles, weapons, animations etc ?

I'm not holding my breath for a positive answer to this but again, if it works then the possibility of having the one addon to allow any scripted addon type effect would be massive !

Can anyone shed some light here ?



roni

[Fragorl]

I can't shed any light, but I can thicken the plot up a li'l:

Once upon a time there was an addon I used, which I absolutely cannot find any more- ronaldcargorope. I'd swear that one of the .pbo files HAD to reside in the mission folder itself- however. This was a long time ago, I had an older version of OFP back then, AND I cannot remember if this was even the case. It doesn't sound right at all, I know. But if anyone knows anything about this, or if it stirs up some vague memories for someone, please tell.

To your question: I have a *reasonably* good theoretical understanding of C++ and reasonable practical experience with Java - to my eye, the .cpp (C Plus Plus?) files are somewhat confusing: the use of the word 'class' especially, I don't quite understand what it means here..... things like defining classes within classes (like class All{}; within CfgAmmo{}; etc), having a semicolon after the final brace after a class description.... Other stuff looks familiar: like the array notation: cloudletColor[]={1,1,1,0}; for example. But then again, there's no declaring of variables.

What I think is, the .cpp files are kind of like chunks of information that the game code uses. They aren't true C++, but once again like ofpscript the syntax has been defined inside the game code (that we can't access), and the game knows how to parse it into information that it can access. It's undoubtedly more subtle than that. But you can't go writing your own methods there (or maybe you can... )

Well, that's my theory, you'll notice I don't try and justify it because 1.) I can't and 2.) that would require work ;D but I suggest you go onto the BIS forums and ask them.

[h-]

But you can't go writing your own methods there (or maybe you can... )

Yup, you can't....

You're right about the config being just a 'list' of information the game engine uses, I think they named the files .cpp/.hpp just for simplicity or something...
It does however look a bit like C++ or C...

But anyway, you can't use any of the 'real' coding stuff, even the #include in configs and .sqf works differently than in C for example...

Could I have just ONE addon consisting of (say) a black box, which whenever it is placed on the map, all it does is call externalConfig.cpp, and have this config define new vehicles, weapons, animations etc ?

Yes, but I'm pretty sure not from the mission folder/pbo...
Because it seems that the 'external' config (.hpp for example) that is called by the main config needs to be in the same .pbo root as the main config is...
So you can't 'call' an external config from say some folder inside the same .pbo as the main config, or from some other .pbo...

Here's one example how you can 'call' another config from within another:

Code: [Select]

class CfgAmmo
{
   class Default{};
   class Grenade: Default {};
   class BulletSingle: Default {};
    class Shell: Default {};
   class Shell105: Shell {};
   class Bullet7_6: BulletSingle {};
   class BulletApers: Bullet7_6
   {
      tracerColor[] ={0,0,0,0};
      tracerColorR[] = {0,0,0,0};
   };
   class Bullet12_7: Bullet7_6 {};

#include "pboname\blahblahProjectiles.hpp"

class CfgWeapons
{
   class Default {};
   class GrenadeLauncher: Default {};
   class Gun73: Default {};
   class Gun105: Gun73 {};
   class MGun: Default {};
   class MachineGun7_6: MGun {};
   class MachineGun12_7: MachineGun7_6 {};

#include "pboname\blahblahGuns.hpp"

class CfgVehicles
etc etc.....If you try to add a longer file path there you just get errors...

Of course, I might be wrong...

[Roni]

Hi HK

Thanks for that, but I'm a bit confused.

Is the "#include" label a command or a comment ?  And when you said "If you try to add a longer file path there you just get errors..." did you mean that your Class definitions can only be soo deep (Class of Class B  . . . of Class X), or did you mean that the path to your external config could only be so deep (/addonname/bits/pieces/odds/sods/etc . . .).

I'm guessing that you meant the latter.  In that case can't you just point to the mission folder itself ?  I was hoping that you might just be able to say "go ahead, run that cpp file in the mision folder and see what's there".  I'm now starting to think that this might not be possible, seeing as the addon will be in the Addons folder and the missin will be in the Missions folder . . .  :tomato:

Oh well, looks like this will be another great theory shot down by pesky facts.



roni

[h-]

Is the "#include" label a command or a comment ?

Without going into semantics, it's a 'command'...
That 'calls' the *.hpp, includes it in the *.cpp 'calling' it...

did you mean that your Class definitions can only be soo deep

It can be just that long as in the example, not longer...
"pboname/file"

And note, you can't use the  \  in the beginning of the path... Just like in that example...
So that alone makes it painfully clear that the thing that is #included must be in the same root as the config its included in... :-\

I think in VBS1 you can read and write into some sort of config (via scripting), so it's not impossible, BIS just didn't give the method for OFP users
Those dirty b******s... ;D

EDIT:

Oh well, looks like this will be another great theory shot down by pesky facts.

Trust me, we all have had them
Of course no-one stops you from trying this thing......

[dmakatra]

Once upon a time there was an addon I used, which I absolutely cannot find any more- ronaldcargorope. I'd swear that one of the .pbo files HAD to reside in the mission folder itself- however. This was a long time ago, I had an older version of OFP back then, AND I cannot remember if this was even the case. It doesn't sound right at all, I know. But if anyone knows anything about this, or if it stirs up some vague memories for someone, please tell.

Could be the testmission y'know.

:beat: *Gets Shot* :beat:

[Fragorl]

Could be the testmission y'know.

:beat: *Gets Shot* :beat:

You know, I think it was. That doesn't help me, as I deleted my old OFP stuff quite some time ago, including the addon and it's mission. I would've liked to see exaclty what was going on there, but oh well.

*Thinks about it some* are you saying that the addon was just included in the mission as a way of including it in one 'package', ie so you got the mission and the addon at once? ie there was no significance in it being in the mission folder? Please elaborate

[Blanco]

I have no idea what you are talking about guys...
But I have found that addon on my HD you were talking about.

http://users.telenet.be/blanco/Scripts/ronaldcargorope.zip (only for 7 days)

[Fragorl]

Cheers blanco!

Looks like I was wrong there's no addon in the mission folder, oh well. At least that satisfies my curiousity!