-= Gametoast.com =-

When I opened the CIS assets, then went into the .odf folder, I noticed that there were, in many cases, 2 .odfs for all of the battledroids. For example, in my case, I wanted to take the shipped .odf of a pilot droid, but there were 2 .odfs, a cis_inf_pilot, and a cis_inf_default_pilot. What i would like to no is, what is the difference between these two .odfs I realize they both contain different information, but is there some special reason for there being 2?

(In case you are wondering, I am wondering this because I think I used the wrong shipped .odf for my mod.)

Any help would be appreciated.

Have a look at the ODF Hierarchy section of the odf_guide.doc in the documentation to understand why Pandemic set up the odfs this way.

Ok so here is what i learned, correct me if I am wrong.

1. cis_inf_pilot is a child of cis_inf_default_pilot.

2. cis_inf_default_pilot is the child of the base unit, cis_inf_default

3. To get my unit working, I am going to need to take the information in both pilot .odfs, and put them together in a combined .odf.

4. The cis_inf_default does not need to be touched at all to get my unit working.

Any help would be appreciated.

Specificly the CIS Pilot for now..

cis_inf_default_pilot:
Weapons used by the unit.
VO Lines. --VO = VoiceOver.
VO Type
And the camera position over the unit.

cis_inf_pilot:
Geometry of the unit
Override textures
Unit skeleton

Unless you want to change the weapons, geometry, add an addon, scale a unit, etc and so forth, you wouldn't need to touch ethier if you wanted it to be default. Which if you just want it default, I would recommend just loading it from the game itself. But, that's just the basics.

Say I wanted to change the weapons, geometry, and texture of the pilot droid that appears in Battlefront 2. Would that mean that I have to take both of those .odfs and combine them together with he correct modifications?

you can, but you dont have to. You can edit both the default and the normal odf file. All properties are carried over to the child odf from the parent odf. You can overwrite these properties in the child odf however by using a function line in the child odf that exists in the parent odf and setting it to something different in the child odf.

It's like how parents pass on genes to kids, but kids sometimes rebel and make their own traits.

Unless you're making a large-scale sides change, in my opinion it's much easier to just copy all the parameters into one .odf (but keeping the parent as com_inf_default). That'll make keeping track of what's overwriting what a lot easier.

Ok, thank you, this thread can now be closed.