An overview of classes

[ZNorQ]

I've started to have a look into the wonderful world of CONFIG.CPPs - and the first thing that strikes me is; It would be nice to have a complete (well, almost anyway) list over the classes and their subclasses and properties.

Does this exist today?

I've started one of my own, but I don't want to go the whole nine yards if there is a really good one out there.

Mine is based on the commented config.cpp from BIS, and have the following fields;

Owner (Who's responsible for the class, ie. BIS)
Super class (Like cfgSFX, cfgVehicles, etc.)
Level 1 Class (First sub class)
Level 2 Class (Second sub class)
Level 3 Class (3rd sub class)
Properties (name, access, sound[], etc. etc.)
Value (A typical value for the property)
Comments (Any of my own - or BIS'es comments)

As per today, I've almost completed the entire CONFIG.CPP, but I haven't gotten around to add the classes in the header/include files. I will be continuing on that if there is no reference list.

PS! Anyone with good knowledge on the commented config.cpp if this covers most of the aspects of what is needed to know about CPP?

ZNorQ

(BTW, if the scope is to big, I might abandon the whole thing, as I'm quite busy making our next OFP LAN get-together...)

[General Barron]

Meh... I'm not exactly sure what you are after.

It would be nice to have a complete (well, almost anyway) list over the classes and their subclasses and properties.

How is this different than the commented config? It contains every class, plus the properties of those classes. Are you trying to somehow 'condense' the config?

Anyway, if you look at the bottom of the Unofficial Com Ref (see the ed depot), there is a 'tree' of object classes. That might be something like what you are after.

[ZNorQ]

Yes, I'm reproducing this information in a spread sheet in order to be able to filter out classes and sub classes to get a better understanding of each class - and their properties.  If you have xls, have a look at the attachment..

(I was thinking of coding a program - instead of a spreadsheet - that presented this info in some sort of a windows treeview control - so one was able to see the hierarcy each element was connected - and the possible/expected values.)

ZNorQ

[ZNorQ]

Ehr, forgot the spread sheet...

ZNorQ

[General Barron]

Yeesh... unless I'm missing something, it looks like you are just copying the commented config into a .xls format. Unless I'm really missing something, it seems like it would be easiest not to re-invent the wheel, and instead just use the existing file format. But again, I must be missing something here...

You also might search the ed depot for 'exploded bins' or something similar. Shinraiden did some sort of catagorizing of the resource.cpp, and possibly config.cpp.

[ZNorQ]

Hehe, well, I'm not exactly an expert on the subject. Just started these last days having a closer look at the config.cpp classes. Also, my english suck, so I think I'm in way over my head here.

Anyway, the reason I wanted to make this xls document, was to be able to filter out elements I was looking for. Now, the xls document will hopefully eventually contain all super classes (cfgVehciles, etc.), and their subclasses and properties. This way, if I wanted to create a vehicle, I could use the filters in xls to select out those elements I'm looking for.

An example; (Data below represent the various columns in the spreadsheet, where 2 filters have been applied; Superclass = CfgInGameUI, and Lvl 1 class = TacticalDisplay)

Super class     Lvl 1 class        Lvl 2 class     Lvl 3 class    Inherit       Property               Value
CfgInGameUI  TacticalDisplay  <none>        <none>         SideColors  Left                   0.24
CfgInGameUI  TacticalDisplay  <none>        <none>         SideColors  top                    0.053
CfgInGameUI  TacticalDisplay  <none>        <none>         SideColors  width                 0.52
CfgInGameUI  TacticalDisplay  <none>        <none>         SideColors  height                 0.1
CfgInGameUI  TacticalDisplay  <none>        <none>         SideColors  colorCamera[]      {0.1, 0.1, 0.1, 0.4}
CfgInGameUI  TacticalDisplay   Cursor          <none>         <none>      width                  0.015
CfgInGameUI  TacticalDisplay  Cursor          <none>         <none>      height                0.02
CfgInGameUI  TacticalDisplay  Cursor          <none>         <none>      color[]                {White, 1}

This would tell me that the super class CfgInGameUI have a TacticalDisplay subclass (which is inherited from the SideColors class), and have 5 properties (left, top, width, height and colorCamera[]). It also have a level 2 class called Cursor, which again contains 3 properties - width, height and color[]. The collection is also showed with the standard values BIS used, just to give an idea what kind of information is expected in these properties..

So, the main purpose is to quickly get an overview over the composition of a super class, instead of browsing through tons of data in an standard ascii format...

Sorry if my poor attempt of explaining myself was a wild shot in the dark here.

ZNorQ

[General Barron]

Also, my english suck, so I think I'm in way over my head here.

Could have fooled me (and you did, actually) .

Anyway, this does make more sense. Personally, whenever I want to see what properties are possible in a 'superclass', I just check the "default" class. Since everything inherits from it, 'default' MUST have every possible property defined.

I can't really add much else to this thread, except links to what I mentioned earlier. It should be a more manageable format of the commented config. Check these two resources:

http://www.ofpec.com/editors/resource_view.php?id=864
http://www.ofpec.com/editors/resource_view.php?id=695

[Mikero]

Oddly enough I'm into the same thing you're trying to do. In my case I plunked it all in a database, not excel.

look here

http://www.andrew.nf/OFP/BedtimeReading/AddonRef/addonreferece.htm

for where I am currently up to.

What I want to achieve is a dictionary, a 'command reference' if you like, for all the 'official' variables the engine understands. Items like

cost=
Accuracy=

Why? Because such a thing doesn't exist currently* for people making addons. They need to look inside say, the commented config to 'see' how a tank is built (eg).

*currently means the only references so far are very rudimentary and mostly guesswork which turned out to be wrong.

Although the above url is hardly filled out yet, it's getting there and really wont present  an insurmountable problem. (If you care to work on it with me, feel free). The dog however is the 2nd reason i wanted to do this (which is where I think you are coming from) and that's get an easy handle on which is a superclass of what. Truck eg = CivTruck eg

So far, the information in the database is too unwieldy to use easily. But I have in mind a search button to just paste in the 'offending' class, to find all its (most times multiple, subclasses)

Yes, and certainly, 'just look at the commented config'. It is after all exactly what we are, and have to do! And admittedly isn't very tough. But, having built a dbase, I've realised that *many* of the classes are just replicas of All{} with the merest of tweaks. (strategic/nonstrategic is a difference in armour value only). Some of this isn't obvious because many of the classes over-ride with *exact* same values as their subclass. Ie, a very large amount of noise.

So, I'm just trying to get a handle on how to present the non-obvious in an easy fashion. I'm not there yet.

Is it all worht the effort?

I really don't know the answer to that. It's a mountain that's there to climb.

[ZNorQ]

@Barron; Yeah, I guess you're right about that default class. And thanks for those tips (2 links) you sent me - downloading and scanning as we speak. I'm learning more and more about this CPP stuff.

@Mikero; I think you're thinking what I'm thinking, but you're able to articulate it better than me I guess. Anyway, had a look at your web page, and this looks like a good source of information. Please hurry up and finish it! As for helping out, I'd love to, but I have 2 main reasons for being abit sceptical; Too afraid to not completely understand the CPP concept and giving the wrong information, AND I'm creating a MP LAN game we're planning to have in half a year or so. I'm doing everything myself, so its alot of work, and therefore can't really commit to anything..  (It's that mountain you mentioned... )

If I do create anything that might help you out, I'll be more than happy to share it with you.

I know I've taken so much from the community, and OFPEC have been my main source. I know I owe something in return, and will in the future try to make an effort to give something back, if I can. (Kinda feel guilty about it too..) Abit off topic, sorry about that.

Some more question though; I see most addons uses a very complex inheritence structure when defining their own classes. Like;
   class All{};
   class AllVehicles:All{};
   class Land:AllVehicles{};
   class Man:Land{};
   class Soldier:Man{};

The way I see it, AllVehicles, Land, Man, etc.  is predefined classes that contains a set of property values, and they are copied to new classes - like Soldier. Why is it necessary to inherit from all classes above "soldier", and not just "Man"?

I know I'm missing the knowledge about some fundamental CPP concept here, so what I'm really after is some documentation of how CPP works, not really the classes itself, I guess..

ZNorQ

[Planck]

I was going to move this to the Addons area, but decided to leave it here for now.

Seems to me it should be in addons as it deals with config.cpp commands.

I'll think about it a bit anyway.  


Planck

[ZNorQ]

Hehe, yeah, it's kinda in a gray area, isn't it?

[h-]

Maybe we need another forum?? ;D

"The Grey Area of Editing - Not quite scripting, not quite AddOning, nothing to do with missions though.."

[Mikero]

Why is it necessary to inherit from all classes above "soldier", and not just "Man"?

the short answer is it shouldn't be.

the longer answer is that's the way the engine works.

The real answer is a surprise (mentioned at bottom)

In a true c++ structure (which is what this class buisiness is trying to imitate) the body of eveything before gets built into the body of the next, but, with OFP, i suspect that what's happening is a pointer-> exists in a chain to point to each successive subclass. What happens' is the engine is looking for a specific moniker. Cost= eg. If it doesn't find it in the first (primary) class, it gets the pointer-> to search the next one, and so on, until it does find a cost=.

All{} is used in this instance to pre-define *everything* to some value, a value, any value, to satisfy the search for the moniker.

Using pointers-> makes exceptionally good memory use. Basically, one copy only of ->All for EVERYTHING. whereas in the classic c++ method a copy of All{} is in every class.

The engine cannot know before hand where all{} is for a given addon it needs the lexical parsing of

Myaddon->thing->men->target->all

to work.
---


BUT !!!!! perhaps you didn't know this

Class MyDefaultSoldier
{
  class All{};
   class AllVehicles:All{};
   class Land:AllVehicles{};
   class Man:Land{};
   class Soldier:Man{};
};

Class CfgVehicles  <<<<MUST be declared
{
 Class MyFantasticSoldier : MyDefaultSoldier
 {
  .....
 };
};

The above 'method' is how you would

#include "MyDefaultSoldier.hpp"
#include "MyDefaultTruck.hpp"
........

#include "MyDefaultHouses.hpp"

[ZNorQ]

Sorry I haven't answered to this thread yet, Mikero. I read through your answer long ago, but I guess I need some time to digest it ..

A very useful tip you gave me - the myDefaultSoldier. Thanks.

Do I understand this right; The super class cfgVehicles sets the rules of what monikers are valid within THAT class. And all{} (and the rest of the classes except the one I create ofcourse)  is just REFERENCED in order for the engine to know where to pull out the default values. All{} is the first one out, so I guess my own class would be inheriting all the default values that are valid for cfgVehicles classes. The next one would give a bit more specifc - down to the "man" class where this would be my final copy and paste session.

But; Does the class "man" lack monikers that might be in the previous class (like "Soldier")? This would be the only reason - as far as I can see - why it would be necessary to inheret from all-of-the-above...

ZNorQ