CfgVehicles Config Reference – Talk

I doubt that the hidden selections array has anything to do with actions. It just defines (together with the cfgModels) which selections on the model can be changed by using setObjectTexture.

>i've probaly badly worded that 1.

i noticed eg, that all soldiers can {medic} while the medic cannot.

so i'll reword it (or you can please)

--Raedor 22:17, 2 July 2006 (CEST)

Again me :) Are you sure that you can't inherit private classes from other configs? I thought the only difference to protected is the fact that you can't createVehicle it... but never tested it, though.

--Raedor 22:25, 2 July 2006 (CEST)

>you're right. access does that. private just stops createVehicle afaik

hiddenselections

I'd write something like this:

"Here you can define selections on the model whose textures can be changed during the game with the command setObjectTexture. The index in this array is the selection number for the setObjectTexture command."

The medic does not have the selection {medic} as it is already textured there (the red cross). For example take a model of your choice with hiddenselection, so eg an East BMP and write this in its init line: this setObjectTexture [0, "\data\duha.pac"] and now you'll see the selection pruh in some nice colours... :) you can check it in the model with odol/o2, the marked selection is named pruh ;)

--

nice.

just go for it Raedor, any and all help appreciated. The context is so big, i'm wading knee deep just trying to flesh a skeleton out. Afaik, there's no documention of this type *anywhwere*, so here is a good start (tm)

--ook? 15:22, 3 July 2006 (CEST)

Okay. :)

--Raedor 16:46, 4 July 2006 (CEST)

Move entries

I know it's been a lot of work already, but wouldn't it do good if, with help of others, we'd move all the entries into single entries so this resembles a bit the Scripting Commands Reference? I think that would do good for the clarity and would also be easier to manage...

--hardrock 11:45, 5 July 2006 (CEST)

Move Entires

Initially that was my thought also.

I originally just started to flesh out the skeleton of each token in my sandbox. with the intention later of breaking it into different pages.

but the more i worked on it, the more i began to *really like* how it was presenting.

a very large number of #crosslinks exist to various related names and (i believe) a user would get frustrated with new pages loading all the time.

Maybe not, and certainly, i'm not fussed over it. I like it as it is, if others, such as yourself, prefer to break it down, then, by all means...

--ook? 06:39, 7 July 2006 (CEST)

Structure of the reference

I think the current structure of this reference is misleading. It is not always possible to destribe configs like you describe scripting commands, i.e. based on the entry name. There can exists entries with the same name in different config location, having different meaning. The config structure is object oriented, with inheritace, and I doubt in can be described well without reflecting this.

It would be more correct (and perhaps even more pratical) to organize config documentation based on config structure, like:

Section describing CfgVehicles

Vehicle config

class Transport .. describe what entries go here,

Car config

class SomeCar

.. describe what entries go here, .. note that all entries valid for transport apply here

--Suma 10:30, 14 July 2006 (CEST)

Re-Organise

I take your point that I've presented this subject more as token names == verbs, as if they were unique things.

I have encountered very very few names that are duplicated in context. Instead, where an unusual name has occurred, I've mentioned it in context to where it might be found (tankturret eg)

The problem I have with what you suggest above is people might just as well read the config.cpp, since bottom line there, it's likely to be far more accurate than the typos introduced here !

Even as it stands now, people will find this an invaluable reference to what on earth a cost=, or a VehicleClass= actually is and does.

Human nature being what it is, they wont want to read the blurb on Turrets and their characteristics, they want to go directly to the name that's offending them so much. icon= eg, and how to use it.

Having said all that, this reference really is (only) about CfgVehicles, to put any more in here about CfgWeapons (eg) would be silly. So, I do take your point, well.

Pehaps best compromise is to open this document out, to variously describe each of the major CfgXYZ's in separate documents, and not specifically treat this index as being all-things-config.