CfgVehicles Config Reference – Talk

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
m (Text replacement - " (={2,})([^ = ])(.*)([^ = ])(={2,}) * " to " $1 $2$3$4 $5 ")
 
(25 intermediate revisions by 8 users not shown)
Line 1: Line 1:
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.
== Structure of the reference ==


>i've probaly badly worded that 1.
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.


i noticed eg, that all soldiers can {medic} while the medic cannot.
It would be more correct (and perhaps even more pratical) to organize config documentation based on config structure, like:


so i'll reword it (or you can please)
=== Section describing CfgVehicles ===


--[[User:Raedor|Raedor]] 22:17, 2 July 2006 (CEST)
==== Vehicle config ====


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.
class Transport
.. describe what entries go here,


--[[User:Raedor|Raedor]] 22:25, 2 July 2006 (CEST)


>you're right. access does that. private just stops createVehicle afaik
==== Car config ====
class SomeCar


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


==hiddenselections==
--[[User:Suma|Suma]] 10:30, 14 July 2006 (CEST)


I'd write something like this:
== Re-Organise ==


"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."
I take your point that I've presented this subject more as token names == verbs, as if they were unique things.


The medic does not have the selection {medic} as it is already textured there (the red cross).
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)
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 ;)


--
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 !


nice.
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.


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)


--[[User:Mikero|ook?]] 15:22, 3 July 2006 (CEST)
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.


Okay. :)
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.


--[[User:Raedor|Raedor]] 16:46, 4 July 2006 (CEST)
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.
 
:Sounds reasonable.
 
:I suggest:
 
:* move this page to CfgVehicles Config Reference
:* remove general talk about config.cpp ..., as this belongs to corresponding general topics, not here
 
:I will do the first step immediatelty. Feel free to follow with the 2nd when convenient for you.
:--[[User:Suma|Suma]] 13:28, 14 July 2006 (CEST)
 
== Integer / float ==
 
In many cases the value is denoted as integer here, even if it is in fact read and understood as float by the engine. As a rule, integer is only used where integral type is dictated by the nature of the problem (like when giving count of something), otherwise float is used. (You should not be confused by the fact the values are often encoded as integer in the main config.bin - you explained this very well in [TokenNameValueTypes]. --[[User:Suma|Suma]] 09:39, 18 July 2006 (CEST)
 
== Turret_Config_Reference ==
 
We should link to [[Turret_Config_Reference]] somewhere on this page, as it is part of the cfgVehicles. --[[User:Raedor|raedor]] 15:50, 5 May 2007 (CEST)
 
:This article lacks info on the subclasses also (e.g. class headlights, reflectors, etc.), they should be listed here to and a link to the turret config reference would fit in there :). --[[User:TeRp|TeRp]] 16:02, 5 May 2007 (CEST)
 
== Value explanation ==
 
Can anyone please describe these two:
 
=== ejectDamageLimit ===
 
  ArmA Float: You can get hurt, but you can't die with vals less than 1.0
  ejectDamageLimit = 0.750000;
 
I don't understand a word here. :(
 
=== ejectSpeed ===
 
  Array: Default {0,40,0};
  ejectSpeed[] = {0,0,0}; // cant eject in a cessna
 
What are the three values of the array about - x, y, z?
 
'''Thank you!''' --[[User:WGL.Q|WGL.Q]] 12:40, 26 August 2007 (CEST)
 
:ejectSpeed is used in planes to simulate something like an ejection seat, so it ''should'' be the velocity in x,y,z direction. --[[User:TeRp|TeRp]] 15:52, 26 August 2007 (CEST)

Latest revision as of 19:23, 31 January 2021

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.

Sounds reasonable.
I suggest:
  • move this page to CfgVehicles Config Reference
  • remove general talk about config.cpp ..., as this belongs to corresponding general topics, not here
I will do the first step immediatelty. Feel free to follow with the 2nd when convenient for you.
--Suma 13:28, 14 July 2006 (CEST)

Integer / float

In many cases the value is denoted as integer here, even if it is in fact read and understood as float by the engine. As a rule, integer is only used where integral type is dictated by the nature of the problem (like when giving count of something), otherwise float is used. (You should not be confused by the fact the values are often encoded as integer in the main config.bin - you explained this very well in [TokenNameValueTypes]. --Suma 09:39, 18 July 2006 (CEST)

Turret_Config_Reference

We should link to Turret_Config_Reference somewhere on this page, as it is part of the cfgVehicles. --raedor 15:50, 5 May 2007 (CEST)

This article lacks info on the subclasses also (e.g. class headlights, reflectors, etc.), they should be listed here to and a link to the turret config reference would fit in there :). --TeRp 16:02, 5 May 2007 (CEST)

Value explanation

Can anyone please describe these two:

ejectDamageLimit

 ArmA Float: You can get hurt, but you can't die with vals less than 1.0
 ejectDamageLimit = 0.750000;

I don't understand a word here. :(

ejectSpeed

 Array: Default {0,40,0};
 ejectSpeed[] = {0,0,0}; // cant eject in a cessna

What are the three values of the array about - x, y, z?

Thank you! --WGL.Q 12:40, 26 August 2007 (CEST)

ejectSpeed is used in planes to simulate something like an ejection seat, so it should be the velocity in x,y,z direction. --TeRp 15:52, 26 August 2007 (CEST)
Retrieved from "https://community.bistudio.com/wiki?title=Talk:CfgVehicles_Config_Reference&oldid=226845"