Correct (sub) class inheritance

[.kju 3245]

Preface:

We have standard BI M113Ambulance.

Its inheritance for the ViewPilot looks like this:

class All;
class AllVehicles: All
{
...
class NewTurret
{
...
class ViewGunner
{
...
};
class Turrets
{
...
};
class ViewOptics
{
...
};
...
};
class ViewPilot
{
...
};
class ViewCargo
{
...
};
class ViewOptics
{
...
};
...
};

class Land: AllVehicles
{
...
};

class LandVehicle: Land
{
...
};

class Tank: LandVehicle
{
...
class ViewPilot: ViewPilot
{
...
};
...
};

class M113: Tank
{
...
};

class M113Ambul: M113
{
...
class ViewPilot: ViewPilot
{
minAngleY = -60;
maxAngleY = 60;
};
...
};

Looks complicated. Isn't so complicated yet.

The M113Ambul only partially re-defines the ViewPilot.

The rest is taken from its mother/father class: "M113".

The M113 class doesn't contain a ViewPilot definition.

Ok next: "Tank".

The "Tank" only re-partially defines the ViewPilot.

The rest is taken from its mother/father class: "LandVehicle".

The LandVehicle class doesn't contain a ViewPilot definition.

Ok next: "Land".

The Land class doesn't contain a ViewPilot definition.

Ok next: "AllVehicles".

Here we go finally.

In AllVehicles the complete ViewPilot is defined.

Easy so far.

Now comes the problem.

Lets say for example we want to re-define partially the ViewPilot

of the M113Ambul. How can this be done without rpt

messages...

//// new

class M113Ambul: M113
{
// internal camera viewing limitations
class ViewPilot///: ViewPilot
{
initFov = 0.72;
minFov = 0.3;
maxFov = 1.5;
};
class ViewCargo: ViewCargo
{
initFov = 0.72;
minFov = 0.3;
maxFov = 1.5;
};
};

Like this (with ///) you'll get:

Updating base class ViewPilot->, by truefov-accurate\config.cpp/CfgVehicles/M113Ambul/ViewPilot/

With this (class ViewPilot: ViewPilot) you'll get:

Updating base class ViewPilot->ViewPilot, by truefov-accurate\config.cpp/CfgVehicles/M113Ambul/ViewPilot/

Any ideas...

[ricki 0]

welcome to true mod trouble

open up truefov_accurate config and delete all access = 3 entries.

edit:

clean arma or running with mods ?

and whats the matter with the rpt entries ?

you want to avoid them ?

[.kju 3245]

Thanks for helping ricki!

Actually its not about access, like written here.

Access was fixed and i posted in the trueMods thread howTo for RG.

I'd like to get rid of these:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Updating base class ...

These don't hurt, however don't we all want to know how its done properly.

[ricki 0]

k

think you CANNOT avoid this message.

see queens gambit addon. rpt is full of some base updating entries

[shinRaiden 0]

You don't want to get rid of that msg, actually that's an extremely crucial help to what you're trying to do.

BIS has set up their

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class m113 : ...

and you've got a notion to go and change it's behavior. There's a couple ways you could do that :

A - hax0r --------------------------------------

Run bin.pbo and vehicles.pbo through eliteness, manually edit the config.cpp files, find a host to push 1gb of data for one line of changes, and laugh at the community while they scream bloody murder about your 'mod' being utterly incompatible with anything and everything, not to mention BIS patches and any sense of MP normalcy.

B - Inheritance --------------------------------------

You can, in your own addon, have something like this :

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class m113 : m113

What does this do? It allows you - provided the access param is set to something proper - to go and update the values of the class, without directly editing the other content files. You can edit pretty much any property then just as if you were writing a child class instead. Note that you should include the appropriate base definition classes that you plan to edit later. So what you'd actually be after is something that logically looks more like this :

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class All;

class AllVehicles: All

{

class NewTurret

{

class ViewGunner;

class Turrets;

class ViewOptics;

};

class ViewPilot;

class ViewCargo;

class ViewOptics;

};

class Land;

class LandVehicle;

class Tank;

class M113;

class M113Ambul: M113

{

...

class ViewPilot: ViewPilot

{

minAngleY = -60;

maxAngleY = 60;

};

...

};

Don't just copy and paste though, double-check on your own to make sure that's all correct class names.

Now what's going to happen here though, is you're updating the viewPilot class in the the M113Ambul class. That's where the

Quote[/b] ]Updating base class ... by ...

message comes in. It's especially crucial for addon developers to watch that, and in my opinion, a list of all those generated in an addon ought to be published in the addon's readme as a documented reference for addon compatibility.

Perhaps this would be another wonderful OFPEC project, a library of classes updated, so you could click a couple drop down boxes and see if the addons match up for compatibility, or if they're flagged as incompatible for modifying the same properties.

[.kju 3245]

Respect and thanks a bunch for this post shinRaiden!

That should be very helpful for people new into config editing.

Hopefully someone can integrate this information into the BIKI.

---

However the problem here is more complicated than it might seem.

Personally I am well aware of this.

The problem here comes from TrueFov-Accurate v1.0 from the

excellent TrueMods package of Rg.

However it is generating still a few (error) message in the rpt.

So I tried to fix em.

I got em down to two.

Those two left are topic of this thread.

The complete config part of interest might help clear it up:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

class All;

class AllVehicles: All

{

class NewTurret

{

class ViewGunner;

class Turrets;

class ViewOptics;

};

class ViewPilot;

class ViewCargo;

class ViewOptics;

};

class Land: AllVehicles{};

class LandVehicle: Land{};

class Tank: LandVehicle

{

class ViewPilot;//: ViewPilot{};

class ViewOptics;//: ViewOptics{};

class Turrets

{

class MainTurret: NewTurret

{

class Turrets

{

class CommanderOptics: NewTurret

{

class ViewOptics;

class ViewGunner;

};

};

};

};

};

class M113: Tank

{

// internal camera viewing limitations

class ViewPilot: ViewPilot

{

initFov = 0.72;

minFov = 0.3;

maxFov = 1.5;

};

class ViewCargo: ViewCargo

{

initFov = 0.72;

minFov = 0.3;

maxFov = 1.5;

};

/*

class ViewGunner: ViewGunner

{

initFov = 0.72;

minFov = 0.3;

maxFov = 1.5;

};*/

class ViewOptics: ViewOptics

{

initFov = 0.72;

minFov = 0.3;

maxFov = 0.72;

};

class Turrets: Turrets

{

class MainTurret: MainTurret

{

class ViewGunner: ViewGunner

{

initFov = 0.72;

minFov = 0.3;

maxFov = 1.5;

};

class ViewOptics///: ViewOptics

{

initFov = 0.72;

minFov = 0.3;

maxFov = 0.72;

};

};

};

};

class M113Ambul: M113

{

// internal camera viewing limitations

class ViewPilot: ViewPilot

{

initFov = 0.72;

minFov = 0.3;

maxFov = 1.5;

};

class ViewCargo: ViewCargo

{

initFov = 0.72;

minFov = 0.3;

maxFov = 1.5;

};

};

Note these two lines too:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Land: AllVehicles{};

class LandVehicle: Land{};

Thats OFP style inheritance.

However with ArmA like (class Land; and class Landvehicle;)

ArmA doesn't eat the cake.

As a summary the problem is a more complex inheritance

structure via various classes and subclasses.

---

Quote[/b] ]Updating base class ... by

Not sure about this.

As far as my observations go, ArmA does not indicate that fact

that a given class gets updated. There is no connection to

access as well here.

It is indicating that the way the inheritance is done, is not correct.

I fixed it for several other classes by making a proper ArmA style

inheritance via the main classes and their subclasses. However

no luck with that one so far.

To make it more obvious here is an example how the inheritance

was done before:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

class ViewPilot;

class ViewCargo;

class ViewGunner;

class ViewOptics;

class CommanderOptics;

class MainTurret;

class NewTurret;

class Turrets;

class CfgVehicles

{

class AllVehicles;

class Land;

class LandVehicle;

class Car;

class Truck;

class Motorcycle;

class Bicycle;

class Tank;

class Air;

class Helicopter;

class Plane;

class Ship;

class SmallShip;

class BigShip;

class ParachuteBase;

class StaticWeapon;

class Man;

...

That is certainly not correct AFAIK.

[shinRaiden 0]

The msg in question is not an error, it is informative only.

You are correct, this section

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Land: AllVehicles{};

class LandVehicle: Land{};

is bad. Note the previous snippet :

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class All;

class AllVehicles: All

{...

While class All does not in fact inherit from anything, let's suppose for the case of examples that it does. We don't care about its parent, all we care about is the pointer to the class called All. So, this is correct :

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class All;

Now in AllVehicles though, we need to open it up to expose the classes to edit later. The net effect of this is that by including the prior parameters, we can reference to them just like normal inheritance. That's why we have the more expanded sample :

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class AllVehicles: All {...

Now if we just had this <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class AllVehicles: All {};

it would be interpreted as a NEW AllVehicles class, completely overriding the existing one, if the access permissions allowed. In theory at least, there was some question about whether it was properly working in OFP, and I haven't checked to see if it behaves as expected in Arma.

As for your example of 'how it was done before', unless something has changed dramatically, that code's not going to work because the subclass definitions are set outside of the CfgVehicles context, when they are actually configured inside the context of subclasses of CfgVehicles.

[sickboy 13]

Even though ViewPilot and other classes aren't defined in Land and LandVehicle classes inside bin.pbo/config.bin ...

Following Shinraidens idea about "class Land: AllVehicles {};" creating a new class I would say you would have to inherit:

class ViewPilot;  and other classes you inherit further down the tree, in the land and landvehicle classes.

I would base that on the fact that ur inheriting these classes in this config as opposed to creating/defining them.

Looking at Wheeled.pbo/ and Tracked.pbo/config.bin, this get's further strenghtended where they call up NewTurret and ViewPilot, in the first class before the Car class:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Land;

class LandVehicle: Land

{

class NewTurret;

class ViewPilot;

};

Hence I would suggest:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Land: AllVehicles

{

class NewTurret;

class ViewPilot;

};

class LandVehicle: Land

{

class NewTurret;

class ViewPilot;

};And so for all subclasses defined further down the tree

[.kju 3245]

Again thanks a lot for the detailed explanation ShinRaiden!

Quote[/b] ]it would be interpreted as a NEW AllVehicles class

It depends on the implementation of BI.

So you might or might not be correct about this.

If tests have confirmed your point, then point taken.

Excellent point Sickboy!

I'll try that one. Sounds comprehensible.

Cheers again to you both!

[shinRaiden 0]

Sickboy's code is functional, but redundant. You only need to expose the classes in the immediate parent of the class you intend to modify, iirc. The rest of the inheritance stack is inferred. Very handy, but makes reading configs in a big project a real monster to track.

[DBO_ 0]

alongtime ago there was discussion of this .

it is here

I think on page 31 it starts with rastovich sorting the old no gun and the discussion develops on page 32.

hope its relevant .

[sickboy 13]

Good point there Shinraiden.