Talk:Prop data

prop_data vs $surfaceprop

I'm a bit confused about when to use $surfaceprop QC command rather than the $keyvalue{prop_data ... QC command.

My propdata.txt includes the warning " // DON'T USE THIS FOR A PROP. USE THE NON.BASE ONES. " for each and every base class ...

Please could someone explain ?--Beeswax 08:11, 30 Mar 2008 (PDT)

Hmm, that's a good question. While both of them theoretically determine physics simulation, I think you'll find that prop_data provides models with additional and overriding information. Why not experiment? --TomEdwards 02:50, 31 Mar 2008 (PDT)

I figured it out by reading the propdata.txt when I wasn't so tired ;) The warning DON'T USE THIS FOR A PROP. USE THE NON.BASE ONES. applies only to the base base class.BASE, eg Metal.Base, as opp the NON.BASE ones such Metal.Small, Metal.Large, etc. --Beeswax 08:56, 1 Apr 2008 (PDT)

As far as I can see, prop_data is used almost exclusively for special attributes of prop_physics models, whereas $surfaceprop is used for anything and everything. As far as I can see, prop_data will not override $surfaceprop or vice versa because the don't seem to define the same object properties.--Beeswax 08:56, 1 Apr 2008 (PDT)

Would it be accurate to say: (Beeswax 12:43, 1 Apr 2008 (PDT))

• Whilst $surfaceprop defines the common collision-event properties (sounds, decals, etc) for almost all VMT materials and MDL models, $keyvalues prop_data deals almost exclusively with the prop_physics model's 'breakable' properties (health & damage, exploding, gibbing and flammability).

breakable vs unbreakable

Have I got this right? :

• All prop_data KVs, except AIWalkable, blockLOS, physicsmode, allowstatic and (possibly?) flammable, apply exclusively to breakable models.
• Setting health 0 makes the model unbreakable, rendering all other breakable KVs redundant.
• All base classes - as it happens - specify only 'breakable' KVs - ie. DamageModifiers, Health and Gibs. So setting "health 0" effectively overrides the "base" KV. ?

(Beeswax 16:09, 2 Apr 2008 (PDT))

prop_type flags for models

Have I got thes right? :

• If the $keyvalues prop_data command is included, StudioMDL will flag the compiled model as a prop_physics_only model which can be used only with a prop_physics entity.
• If the $keyvalues prop_data allowstatic 1 command is included, StudioMDL will flag the compiled model as a prop_physics_static model, which can be used with a prop_static or a prop_physics entity.
• $staticprop does not override $keyvalues {prop_data {allowstatic 0}}.
• If the $keyvalues prop_data command is not included, StudioMDL will flag the compiled model as a prop_dynamic_only model, which can be used only with a prop_dynamic entity.
• If the $keyvalues prop_data command is not included but the $staticprop flag is set, StudioMDL will flag the compiled model as a prop_dynamic_static model, which can be used with a prop_static or a prop_dynamic entity.

(Beeswax 12:17, 2 Apr 2008 (PDT))

Article Structure & layout

Please do not edit or delete what you do not understand. Use the discussion page instead. --Beeswax 08:56, 1 Apr 2008 (PDT)

1. Please Do not DELETE statements made by other VDC wiki users. The function of a wiki is to collate information from multiple users. By all means clarify the wording or integrate it into a better context, but don't just delete it because it does not interest you. Someone had reason enough to bother putting it there in the first place. (Beeswax)

2. If you are absolutely certain something is incorrect either raise the issue on the discussion page (using a reference link to your point from the appropriate part of the main article) or correct the article and draw attention to it in the edit summary or discussion page - and be prepared to justify your decision. If you have doubts or reservations about the accuracy of a statement by another user - voice then on the discussion page.(Beeswax)

QC syntax examples

1. Precise titles, like QC syntax example, are more useful than bland titles like Simple Example.(Beeswax)

1. Key value syntax: By including "quotes" around value strings (even when not strictly necessary for correct code-interpretation) readers can easily see what is a Key and what is a Value. (Beeswax)

   Using quote marks in articles achieves that, but also encourages readers to type them in their own code - which as you say is usually unnecessary, and as I expect you probably realise always irritating. ;-) I prefer to use presentation for distinction: either bold key normal value, or using tab characters to align everything into columns. Preferably both. --TomEdwards 10:55, 1 Apr 2008 (PDT)

   Actually, bold/normal weighting it best reserved for when we want a particular KV to stand out from a code block. --TomEdwards 11:01, 1 Apr 2008 (PDT)

   yeah I liked the idea of using bold to highlight the salient code. But I'm right in saying that if someone uses unnecessary "quotes" in their real code, it doesn't actually do any harm does it? I think it would be worth pointing this out somewhere, perhaps in the keyvalue article?(Beeswax)

   It does no harm, but it does no good either. I'll be writing a VDF article at some point to cover this. --TomEdwards 12:58, 2 Apr 2008 (PDT)

   I noticed that propdata.txt uses "quotes" around each key and each value. I'm not sure where that leaves us, but remaining inkeeping with Valve's style would seem advantageous in some respects ... ? (Beeswax 16:27, 2 Apr 2008 (PDT))

   Tom I just realised you created the VDF syntax highlighters for Notepad++ ... nice one! wouldn't it be oh so useful if someone could write a mediawiki VDF syntax highlighter extension that could automatically color-code (and link) syntax for example-code boxes on VDC pages. It could also auto-append/prepend a section header or something indicating the syntax-type eg QC, VMT, etc and even a "QC help" link to helpful articles ... ? whaddya think? --Beeswax 10:19, 6 Apr 2008 (PDT)

   Anyone could do that. It's just pasting a list of values into a box somewhere. :-p But would Valve implement it? Could they, on this wiki version? --TomEdwards 10:34, 6 Apr 2008 (PDT)

   That's the $million query ... it would have to work with this archaic version of mediawiki ;-) --Beeswax 22:18, 6 Apr 2008 (PDT)

1. //Comments: Code examples should generally be kept clear of //comments which distract from the active code.(Beeswax)

   I think we can trust readers to differentiate between the code and comment, especially if the comment is italicised. When and if any issues of distraction are overcome, inline comments explaining each line of code in turn and in the same visual space are undeniably superior teaching tools to a chunk of text beneath. --TomEdwards 10:55, 1 Apr 2008 (PDT)

   Maybe its just me or courier font (or whatever my Firefox default FWF is!) but using italics on fixed-width-fonts seems to render the text very difficult to read, and IMO should be avoided. (Beeswax)

   I agree that inline comments do have their uses, but they should not interfere with the shape of the active code. I'm finding it difficult to describe what I mean! ...

exmaple 1 - bad (OK so I'm exaggerating ... but AFAIK the compiler wouldn't complain at this)

$keyvalues {
  prop_data {
           fire_interactions {
                 ignite halfhealth//Will ignite on reaching 50% health.
                 explosive_resist yes//Clamp blast damage so that the 
                                   //prop ignites instead of breaking.
                 flammable yes//Can be ignited by fire and explosions.
                 }
         }
}

example 2 - good (IMO much easier to read - better use of white space?)

$keyvalues 
{
  prop_data
  {
     fire_interactions
     {
        ignite      "halfhealth" 	// Will ignite on reaching 50% health.
        explosive_resist   "yes" 	// Clamp blast damage so that the prop ignites instead of breaking.
        flammable          "yes" 	// Can be ignited by fire and explosions.
     }
   }
}

Also, for indenting I prefer to use 3 char_spaces as TAB_spaces can vary between Browsers and if oversize can push long lines //comments text off the screen. I have an issue with line-breaking comments: I wish they were always avoidable. (Beeswax)

Having larger fonts or a smaller screen or a user stylesheet can cause the same issue; you can't control those sorts of things on the web without overflow:auto in CSS to create scrollbars inside the element. (Which is a neat idea. Hey Jeff!) Tabs are easier to handle and mean smaller page sizes, particularly if there's a lot of indentation going on.

Anyway. This is what italicised, tab-aligned code looks like on my machine:

Those are Windows Vista fonts, so It's not surprised that things aren't so legible on other OSes. Nevertheless, even without the comments' italicisation it's pretty clear to me what's what. --TomEdwards 12:58, 2 Apr 2008 (PDT)

Jeez I really wish mine looked that good :-( BTW your indents seem to have shrunk ... you are using a real fixed-width-font ?(Beeswax 16:03, 2 Apr 2008 (PDT))

The tabs at the start are spaces. I forgot to mention it, but I'd tried collapsing down the tabs from parent KVs that weren't important in that screenshot. Think it works? --TomEdwards 10:34, 6 Apr 2008 (PDT)

Hmm - I'm not sure. It does make it a little harder to 'line-up' the brackets and read the phrasing. It's not so bad on this example but in bigger code chunks it could be more significant. I thought 3 char spaces was pushing it ...--Beeswax 22:18, 6 Apr 2008 (PDT)

Problem QC for model physic

I make this QC and the model in CSS is not possible of break :

$modelname	"boxe_phy\boxe_phy.mdl"		
$cdmaterials	"models\boxe_phy\"
$body mybody	"boxe_phy_ref.SMD"			
$sequence idle	"boxe_phy_idle.SMD"	
$collisionmodel  "boxe_phy_phys.SMD"
{
$mass		5
$concave 
}
$keyvalues
{
prop_data
{
base			Metal.Large
health 			10
breakable_model		GlassChunks
}
}

Thx. Anarkia777. PS : It's ok I forgot "breakable_count".