Talk:Prop data

QC: $keyvalues 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))

• The prop_data set of $keyvalues is used to define the breakable properties of a physics model for use as a prop_physics entity.

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

• Thus, by default, models with a prop_data section will be compiled with the prop_physics flag, which means that if a level designer tries to use this physics model as a prop_static (or prop_dynamic?) entity, Hammer's BSP compiler will remove it from the map and report the Error in the compiler log. However, the prop_data 'flag' allowstatic 1 can be used to override this default limitation; allowing the breakable physics model to be used as a movable, breakable prop_physics or an unmovable, unbreakable prop_static.

• 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. So setting "health 0" effectively overrides the "base" KV. ?

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)

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)