Inherit BIS Model and Skeleton def

[[aps]gnat 28]

I'm looking for a simple way to inherit a standard BIS model and skeleton definition, without having to re-define everything again, which is the only thing that seems to work for me.

i.e. so a model with the same named sections will animate straight away.

The below doesnt work;

Quote[/b] ]class cfgModels

{

class default{};

class ural: Default

{

sections[] = {};

};

class truck02: ural{};

Even this which Id expect should, doesn't

Quote[/b] ]class cfgModels

{

class ural;

class truck02: ural

{};

Checked some other ppls addons, they either seem to be re-defining everything again (like me) or even over-definiing their addon and more.

[General Barron 0]

You should be able to extract the BIS model.cfg's into your P: drive. When packing, Binarize will automatically spider up the directory tree, looking for model.cfg's. Ex:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">P:\ca\yourAddon //your addon goes here

P:\ca\model.cfg //all BIS model.cfg's crammed into this file

[Synide 0]

If I build...

P:\Synide\synBodies into a <ArmAGameInstallationFolder>\Synide\AddOns\synBodies.pbo...

With BinPBO settings of...

           Addon Source Folder = P:\Synide\synBodies

           Destination Folder = C:\Games\ArmA\Synide\AddOns

           Binarize=Yes, Clear Temp Folder=Yes

           Path To Project Folder = P:\Synide

           Addon Prefix = Synide\synBodies

Then Binarize.exe will go looking in the following places for CfgSkeletons & CfgModels stuff...

        1. It looks for a file called 'synSASAssault.cfg' in the folder 'P:\Synide\synBodies' - reason is it's one of the models being processed by binarize.

        2. If 'synSASAssault.cfg' is found it is parsed...

        3. Then binarize tries to find a .cfg file that's called the same name as the folder. eg. 'synBodies.cfg' and if found is parsed.

        NOTE: If a 'synBodies.cfg' was found then step 4 is bypassed.

         4. Then binarize tries to find a model.cfg and if found is parsed.

         5. Then binarize tries to find a .cfg file that's called the same name as the 'project' folder. eg. 'Synide.cfg' and if found is parsed.

         5. Finally binarize tries to find a .cfg called 'model.cfg' in the root folder of your P:\ drive.

The above description of what & where binarize.exe looks for .cfg files is different to how it looks for .cpp files.

So, if you want to do a proper inheritance structure for your skeletons then...

In my case I define global CfgSkeletons & CfgModels definitions in my P:\Synide\Synide.cfg that are generic to ALL subfolders of P:\Synide.

Then in each subfolder of P:\Synide... like P:\synBodies\synBodies.cfg I define generic skeletons etc. that are just for 'character' models. I prefer to call the file 'synBodies.cfg' as when I'm scanning across many folders sometimes I get lost when they are all called 'model.cfg'.

And, for instance in P:\Synide\synWpns there's a synWpns.cfg that defines skeletons etc. just for weapons.

As I don't have very many models inside synBodies I have chosen to just add the specific model defintion to the end of the synBodies.cfg as oppossed to creating seperate <modelname>.cfg's for each model...

Finally, personally I do not make use of a 'model.cfg' file in the P:\ root folder as it's a waste of time...

So when you define your .cfg's in this way binarize.exe can successfull 'walk-the-tree' looking for bones & anims you inherit from and it means you can have resonably 'clean' .cfg's.

Understanding the above & also understanding how & where binarize.exe goes looking for config.cpp is crucial to building addons successfully.

@General Barron... It's bad form to stick your addons into another mod teams 'namespace' when you don't have too... I know the BIS guys probably don't care... but would RKSL, HWM, CWR kick up a stink if we all started releasing addons inside their mod's/namespaces? I think so...

I recommend sticking to P:\<YourModNameORRegisteredPrefixORCommunityName> and learn howto build your addons well...

[[aps]gnat 28]

...................... ok

None of that was "a simple way".

Yes I use BinPBO, thats what above didnt work with.

I'm looking for a simple way to (re)define a model and skeleton using classes already know to the application.

[UNN 0]

Quote[/b] ]I'm looking for a simple way to (re)define a model and skeleton using classes already know to the application.

I don't think you can inherit skeleton classes the same way you can with vehicles e.t.c

I've not looked into the method Synide posted, but it looks like a good way to work if you have lots of different pbo's sharing the same model.cfg. But again I don't think it works like the inheritance we know with cfgVehicles?

@Synide, is that correct? Or will Binarize look to inherit any of the classes it finds in the cfg's, through steps 1 to 5?

I just use #include files for all the common bone properties e.t.c.

[[aps]gnat 28]

But again I don't think it works like the inheritance we know with cfgVehicles

Ok, then that being the case it goes some way towards explaining GBs and Synide answer.

But is including a whole tree of pre-defined definitions potentially "overloading" your own addon with unnessisary "data", buried in the p3d (?) ?

[Synide 0]

yeah, binarize.exe will look to inherit definitions... but only from the files mentioned... that's as far as binarize.exe goes when it scans for .cfg's.

This is quite different to what it does when it goes looking for config.cpp's tp parse... it goes searching over a wider area...

so in my setup... in synBodies.cfg i have something like the following excerpt...

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

 class Default;

 class Flag: Default {};

 class FlagCarrier: Default {skeletonInherit="Default";skeletonBones[]={"stozar","","vlajka",""};};

 class Head {isDiscrete=0;skeletonInherit="";skeletonBones[]={"neck","","neck1","neck","head","neck1","lBrow","head","mBrow","head","rBrow","head","lMouth","head","mMouth","head","rMouth","head","eyelids","head","LLip","head"};};

 

 class synManSkeleton {isDiscrete=0;skeletonInherit="Head";skeletonBones[]={"weapon","","launcher","","Camera","","Spine","","Spine1","","Spine2","","Spine3","","Pelvis","","LeftShoulder","","LeftArm","","LeftArmRoll","","LeftForeArm","","LeftForeArmRoll","","LeftHand","","LeftHandRing","","LeftHandRing1","","LeftHandRing2","","LeftHandRing3","","LeftHandPinky1","","LeftHandPinky2","","LeftHandPinky3","","LeftHandMiddle1","","LeftHandMiddle2","","LeftHandMiddle3","","LeftHandIndex1","","LeftHandIndex2","","LeftHandIndex3","","LeftHandThumb1","","LeftHandThumb2","","LeftHandThumb3","","RightShoulder","","RightArm","","RightArmRoll","","RightForeArm","","RightForeArmRoll","","RightHand","","RightHandRing","","RightHandRing1","","RightHandRing2","","RightHandRing3","","RightHandPinky1","","RightHandPinky2","","RightHandPinky3","","RightHandMiddle1","","RightHandMiddle2","","RightHandMiddle3","","RightHandIndex1","","RightHandIndex2","","RightHandIndex3","","RightHandThumb1","","RightHandThumb2","","RightHandThumb3","","LeftUpLeg","","LeftUpLegRoll","","LeftLeg","","LeftLegRoll","","LeftFoot","","LeftToeBase","","RightUpLeg","","RightUpLegRoll","","RightLeg","","RightLegRoll","","RightFoot","","RightToeBase",""};};

};

class CfgModels {

 class Default;

 class flag_vojak: Default {sections[]={"latka"};};

 class Head: Default {sections[]={"osobnost","brejle"};skeletonName="Head";};

 class synMan: Default {sections[]={"osobnost","Head_Injury","Body_Injury","l_leg_injury","l_arm_injury","r_arm_injury","r_leg_injury","clan"};skeletonName="synManSkeleton";};

class synSASAssault: synMan {};

};

notice that there is no definition for 'Default'... this is found by binarize.exe when it parses P:\Synide\Synide.cfg one folder up from P:\Synide\synBodies... So, it's inheriting 'class Default;' from the Synide.cfg.

As another example my synBuildings folder has some building models and as you'd expect in the synBuildings.cfg the bones & animations are defined. But in the file there is just a reference to 'class Rotation;'

When binarize.exe parses synBuildings.cfg it successfully inherits the fully defined 'class Rotation;' from the Synide.cfg file it goes looking for in the 'Project' folder.

Please note... This IS the proper/correct method for defining your skeletons and animations.

If you want to check for yourself run Filemon.exe from sysinternals while your running BinPBO... all will be revealed...

I wrote all this up in that 'Development Environment Setup' .pdf posted somewhere here in the Editing troubleshooting forum... i think...

PS. sorry about the width...

[Synide 0]

Quote[/b] ]But is including a whole tree of pre-defined definitions potentially "overloading" your own addon with unnessisary "data", buried in the p3d (?) ?

Nope... it only uses what it needs too...

The problem arises with the way binarize.exe processes .cfg's when you get the following scenario...

In P:\Synide\Synide.cfg lives common definitions for skeleton & anim stuff that all subfolders (nee. pbo's) can inherit from.

Up until now I've only had one 'characters' related .pbo and that's synBodies. So, as a management decision I have defined all skeleton stuff in synBodies.cfg because it's not needed anywhere else...

But, next week I decide to make a new .pbo based from P:\Synide\synBodies2

Now in this new folder I'll have a synBodies2.cfg that will try to just inherit the skeleton stuff from synBodies... that would be nice but unfortunately binarize.exe won't even go near that folder when trying valid my new synBodies2.cfg... a real shame...

The only way around this scenario is to 'replicate' the same stuff from synBodies.cfg over to synBodies2.cfg... OR... move the character related defintions out of synBodies.cfg up too P:\Synide\Synide.cfg... If placed here then when I build synBodies binarize.exe will also parse Synide.cfg inheriting from it... AND, when I build synBodies2 binarize will inherit from Synide.cfg...

Eg.

P:\Synide\Synide.cfg

               |

               |> P:\Synide\synBodies\synBodies.cfg

               |

               |> P:\Synide\synBodies2\synBodies2.cfg

You can keep P:\Synide\Synide.cfg resonably tidy by making it full of '#includes' ...

In the above scenario I now have 2 'character' related .pbo's and the models therein both inherit the skeletal defintions etc. from P:\Synide\Synide.cfg.

It might be tidier to move to this sort of structure...

P:\Synide\synBodies

P:\Synide\synBodies\BigHairyMen

P:\Synide\synBodies\DaintyWomen

However as soon as you start moving models you have to start repathing textures... yuck...

The way binarize.exe goes looking for .cfg related should in my opinion be same as how it goes looking for .cpp related stuff... this is one of a number of annoying traits of binarize.exe... OR, if binarize.exe processed "#includes" to not only do subfolders but also do relative paths then problem solved...

You could get around all of this by not using .cfg files at all and not integrating your skeletons and anims into your models... moving it all into the config.cpp's - but that sorta defeats the whole intent of having these features in the first place now doesn't it?

[Synide 0]

lol, look Gnat... and everyone else who's interested... I know you want simple answers and simple solutions....

But, week after week I see frik'n posts all over these forums from people having problems building, defining and inheriting from stuff...

Well established Mod Teams (people who should know better) are even stuffing things up so don't get too concerned that this all sounds complicated or difficult...

If you want a really simple solution... create the following structure for yourself...

P:\Gnat

P:\Gnat\Gnat.cfg

- Put all the stuff from model.cfg from the BIS \ca\model.cfg file that came from the example mlods.

P:\Gnat\gnatVehicles

P:\Gnat\gnatVehicles\gnatVehicles.cfg

- Put all the stuff from the model.cfg from BIS \ca\wheeled\model.cfg that came from the example mlods.

Add to the bottom of gnatVehicles.cfg any specific models you have sitting in gnatVehicles folder.

Not ideal but should suffice... btw... none of this stuff is hard it's all really simple stuff... I know I've given you too much info... but you really, really need to come to grips with how binarize.exe works...

Ok... I've just decided that this whole building stuff in ArmA needs to be put to bed... I'll make a series of Video Tutorials.

[[aps]gnat 28]

Ok... I've just decided that this whole building stuff in ArmA needs to be put to bed... I'll make a series of Video Tutorials.

LOL ... ok, sounds like a plan

As for the rest, thank you, its just I'm going to have to re-read it several times to understand all that

[General Barron 0]

Gnat @ Aug. 12 2008,04:46)]I'm looking for a simple way to (re)define a model and skeleton using classes already know to the application.

It doesn't work that way. Synide knows what he is talking about and has said it all, but I'll just try saying it a different way.

The model.cfg info is "baked" into the model during binarization. It doesn't work like configs, which are dynamically loaded / built when you start the game.

All the data is stored when you binarize the addon, and it can not be changed by other addons you may have installed when you run Arma. Nor can the data in your model change the data in someone else's model.

To put it another way, your Arma install has no influence on the model during binarization. Binarize itself doesn't have any info stored inside of it, since it is designed to be flexible (you can define your own skeletons, they aren't hardcoded into binarize).

So all the info needs to be in your P: drive, in the form of model.cfg's, when you run binarize.

Where does that info need to be? Luckily, it doesn't all have to be in the folder you are packing. Binarize will first look in the folder you are packing; then it will look in its parent folder, then its parent's parent folder, and so on until it reaches the root directory.

Note: binarize only bakes the info into a model that you tell it to. If you inherit from the car base class, then it will ONLY bake the car data into your model; even if you have a person base class in the same model.cfg. (The person base class just gets ignored in this case, until you binarize a model that inherits from the person base class)

So the simplest thing to do is to put all of your base model.cfg definitions into your root directory, or in your highest level directory (eg: P:\ca). You then make a smaller model.cfg in your addon's directory, and inherit from the appropriate base class, and only add the things that make THIS addon unique from the base class. Again, see the sample BIS stuff; this is how they are set up.

It's not the easiest thing in the world to get your head around, but the system is designed so you can make a whole lot of content in an organized manner. This is how BIS made all of the Arma content.

If you are only making a single addon, then I could see how the whole structure could seem like more work then its worth. But it is designed to make content for an entire mod / game, not a single addon.