Talk:CfgVehicles Config Reference

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)